Hi Seil,
在 2015年4月13日 星期一，下午10:02，Seil Jeon 写道： > Hi Dapeng, > > I think your draft should not be compared with our draft. Our draft is > proposing some missing points through case study based on the on-demand > mobility draft. > Your draft seems proposing a different way, which is away from the on-demand > mobility draft, from the definition of the proposed flags for local HNP and > remote HNP. It should be checked first. > > > OK. I see your point. Then they aim to solve different problems. Regards, Dapeng Liu > > > --------- > The local home prefix may be preferred by applications which are > likely to discontinue operations before the device travels to distant > networks. On the other hand, a remote home prefix may be more > suitable for continued operation over wide areas, but at potentially > increased cost for mobiilty management. > --------- > > > Best Regards, > > Seil Jeon > > From: Dapeng Liu [mailto:maxpass...@gmail.com] > Sent: Monday, April 13, 2015 2:47 PM > To: Moses, Danny > Cc: Seil Jeon; dmm@ietf.org (mailto:dmm@ietf.org) > Subject: 回复： [DMM] Answer on raised questions for the proposed API > > 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:maxpass...@gmail.com] > > Sent: Monday, April 13, 2015 16:28 > > To: Moses, Danny > > Cc: Seil Jeon; dmm@ietf.org (mailto:dmm@ietf.org) > > 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: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. > > > > > > > > > > > > --------------------------------------------------------------------- > > 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
