Hi Danny, If you have read http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00,
The main idea of the draft is proposing to define the following flag: 3.1 (http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00#section-3.1). Suggested indication flag IPV6_PREFER_SRC_NEW /* Prefer a new IP address based on a requested IP address type as source */ This flag is proposed to be added in RFC5014 (http://tools.ietf.org/html/rfc5014), and aims to express the preference for enabling differentiated per-flow anchoring. The use of the flag can be combined together with the three types of IP address defined in [draft-yegin-dmm-ondemand-mobility (http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility)]. It is in equal degree and orthogonal with the defined flag-set in IPv6 socket API for source address selection [RFC5014 (http://tools.ietf.org/html/rfc5014)]. What I’m asking to Seil is: is this proposal has similarity with the main idea of 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 In the above drafts, the main idea is to define: IPV6_PREFER_SRC_LOCAL_HNP /* Prefer a local home prefix */ IPV6_PREFER_SRC_REMOTE_HNP /* Prefer a remote home prefix */ Regards, -- Dapeng Liu 在 2015年4月13日 星期一，下午9:31，Moses, Danny 写道： > Again – what exactly are you comparing? Please be more specific. > > From: Dapeng Liu [mailto:[email protected]] > Sent: Monday, April 13, 2015 16:28 > To: Moses, Danny > Cc: Seil Jeon; [email protected] (mailto:[email protected]) > Subject: 回复： [DMM] Answer on raised questions for the proposed API > > > > 在 2015年4月13日 星期一，下午9:21，Moses, Danny 写道： > > > > What is simpler. Can you be more specific? What are you comparing? > > > > > > > > > > “similar" not “simpler”. > > > > > > Regards, > > Dapeng Liu > > > > > > > > > > > > > Thanks, > > > > > > /Danny > > > > > > > > > > > > From: Dapeng Liu [mailto:[email protected]] > > Sent: Monday, April 13, 2015 15:54 > > To: Seil Jeon > > Cc: Moses, Danny; [email protected] (mailto:[email protected]) > > Subject: 回复： [DMM] Answer on raised questions for the proposed API > > > > > > > > > > > > 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: > > > > > > > > > When an application chooses not to specify a source address (but request > > > a specific type) > > > > > > > > > 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: > > > > > > > > > When an application chooses not to specify a source address (but request > > > a specific type) > > > > > > > > > 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: > > > > > > > > > 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 - > > > > > > > > > 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) > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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
