在 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:maxpass...@gmail.com] > Sent: Monday, April 13, 2015 15:54 > To: Seil Jeon > Cc: Moses, Danny; dmm@ietf.org (mailto:dmm@ietf.org) > 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:danny.mo...@intel.com] > > Sent: Sunday, April 12, 2015 1:49 PM > > To: Seil Jeon > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > 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:seilj...@av.it.pt] > > Sent: Sunday, April 05, 2015 17:08 > > To: Moses, Danny > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > 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:danny.mo...@intel.com] > > Sent: Sunday, April 05, 2015 12:23 PM > > To: Seil Jeon > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > 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:seilj...@av.it.pt] > > Sent: Sunday, April 05, 2015 01:16 > > To: Moses, Danny > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > Subject: RE: [DMM] Answer on raised questions for the proposed API > > > > > > > > > > > > > > > > Resent. > > > > > > > > > > > > Seil > > > > > > > > > > > > > > From: Seil Jeon [mailto:seilj...@av.it.pt] > > Sent: Saturday, April 04, 2015 1:35 PM > > To: 'Moses, Danny' > > Cc: 'dmm@ietf.org (mailto:dmm@ietf.org)' > > 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:danny.mo...@intel.com] > > Sent: Thursday, April 02, 2015 2:16 PM > > To: Seil Jeon > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > 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:seilj...@av.it.pt] > > Sent: Tuesday, March 31, 2015 15:23 > > To: Moses, Danny > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > Subject: RE: [DMM] Answer on raised questions for the proposed API > > > > > > > > > > > > > > > > Hi Danny, > > > > > > > > > > > > See the inline please. > > > > > > > > > > > > > > > > > > Seil Jeon > > > > > > > > > > > > > > > > > > > > From: Moses, Danny [mailto:danny.mo...@intel.com] > > Sent: Monday, March 30, 2015 4:44 PM > > To: Seil Jeon > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > 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:seilj...@av.it.pt] > > Sent: Monday, March 30, 2015 17:08 > > To: Moses, Danny > > Cc: dmm@ietf.org (mailto:dmm@ietf.org) > > Subject: FW: [DMM] Answer on raised questions for the proposed API > > > > > > > > > > > > > > > > Hi Danny, > > > > > > > > > > > > Any comments? > > > > > > > > > > > > Regards, > > > > > > Seil Jeon > > > > > > > > > > > > > > > > > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Seil Jeon > > Sent: Thursday, March 26, 2015 8:08 PM > > To: dmm@ietf.org (mailto:dmm@ietf.org) > > 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 > > > > dmm@ietf.org (mailto:dmm@ietf.org) > > > > 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.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
