Hello Seil, Danny： [as an individual contributor]
You can refer to the following two drafts: https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 Is it the similar idea? -- Dapeng Liu 在 2015年4月13日 星期一，上午6:03，Seil Jeon 写道： > Hi Danny, > > From your cases specified as follows; > > “I am thinking of two places that might require an update: > 1. When an application chooses not to specify a source address (but > request a specific type) > 2. When an application wishes to choose the source address from a > provided list. > “ > > I don’t understand the meaning of the second case. Why should an application > wish to choose a source address from a list? What I have talked about was > about allowing the default source address selection rules, which will be > determined in the IP stack when an application is initiated with the > destination address. I think we don’t need to touch it. > > The point is an application will totally assign the default source address > selection mechanism based on only type request but with no preference, or > will request with the preference of a new Sustained IP address as well as > type request. In the former case, if there is one or multiple Sustained IP > addresses, the IP stack will try to pick up one. Or the IP stack will try to > get a new one. In the latter case, the IP stack will consider a newly > obtained Sustained IP address all the time, if the requested preference value > is not less than other preferences defined in the default source address > selection rules. > > The need of the proposed flag and main criteria to be considered were already > covered with case studies in the draft. > http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00 > > So, for productive discussion, I would like to suggest that you check our > draft again please and bring your questions if there is something weird or > should be updated with additional cases. > > > Best Regards, > > Seil Jeon > > > From: Moses, Danny [mailto:[email protected]] > Sent: Sunday, April 12, 2015 1:49 PM > To: Seil Jeon > Cc: [email protected] (mailto:[email protected]) > Subject: RE: [DMM] Answer on raised questions for the proposed API > > You have a good point here. > > Now I understand the need for the flag you are proposing !!! > > > We need to take a better look at RFC 6724 and figure out if we need to update > it. > > I am thinking of two places that might require an update: > 1. When an application chooses not to specify a source address (but > request a specific type) > 2. When an application wishes to choose the source address from a > provided list. > > When the application indicates the desired address type, but chooses not to > specify the source address (from a list provided by the IP stack), the stack > should allocate a source IP address according to the address-type requested > by the application. In this case, we should consider adding text to describe > the behavior for Sustained IP addresses. Specifically, if there are several > Sustained IP addresses allocated to the mobile host, whether to choose one of > them, or to have the mobile host request a new one from the network (as a > result of a mobility event – for example). > > When an application wishes to chooses the source address from the available > list (obtained by getaddrinfo()), there are some alternative approaches we > should consider: > 1. Enhance getaddrinfo() enabling the application to specify the > required address type, and return the list of source addresses that are of > that type (Nomadic, Sustained, Fixed or DontCare), or - > 2. Provide the list of addresses with an indication of their type > (Nomadic, Sustained, Fixed or TypeUnknown) and an indication of whether each > address is New (allocated after the last handoff event) or Old (allocated > before the last handoff event) > 3. Some other approach… > > The flag is need here, to enable the application to request a new IP address > (if the returned list only contain 'Old' addresses) !!! > > I agree that we should discuss this. How about bringing it to the next > 'Mobility Exposure and Selection WT' call? > > Regards, > /Danny > > From: Seil Jeon [mailto:[email protected]] > Sent: Sunday, April 05, 2015 17:08 > To: Moses, Danny > Cc: [email protected] (mailto:[email protected]) > Subject: RE: [DMM] Answer on raised questions for the proposed API > > 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 > (http://of.it). > If an application has the specific preference of a newly obtained Sustained > IP address, it uses the proposed API. > > Regards. > Seil > > > From: Moses, Danny [mailto:[email protected]] > Sent: Sunday, April 05, 2015 12:23 PM > To: Seil Jeon > Cc: [email protected] (mailto:[email protected]) > Subject: RE: [DMM] Answer on raised questions for the proposed API > > 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] (mailto:[email protected]) > Subject: RE: [DMM] Answer on raised questions for the proposed API > > Resent. > > Seil > > > From: Seil Jeon [mailto:[email protected]] > Sent: Saturday, April 04, 2015 1:35 PM > To: 'Moses, Danny' > Cc: '[email protected] (mailto:[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]] > Sent: Thursday, April 02, 2015 2:16 PM > To: Seil Jeon > Cc: [email protected] (mailto:[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]] > Sent: Tuesday, March 31, 2015 15:23 > To: Moses, Danny > Cc: [email protected] (mailto:[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]] > Sent: Monday, March 30, 2015 4:44 PM > To: Seil Jeon > Cc: [email protected] (mailto:[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]] > Sent: Monday, March 30, 2015 17:08 > To: Moses, Danny > Cc: [email protected] (mailto:[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]] On Behalf Of Seil Jeon > Sent: Thursday, March 26, 2015 8:08 PM > To: [email protected] (mailto:[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. > --------------------------------------------------------------------- > 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] (mailto:[email protected]) > https://www.ietf.org/mailman/listinfo/dmm > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
