Subject: Re: [DMM] Answer on raised questions for the proposed API

From: "Moses, Danny" <[email-masked]>
Date: Thu, 2 Apr 2015 13:16:16 +0000

Hi Seil,

Please see my replies (surrounded by  >>2) to yours.

Regards,
                /Danny

From: Seil Jeon [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Danny,

See the inline please.

Seil Jeon

From: Moses, Danny [mailto:[email-masked]]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: [email-masked]<mailto:[email-masked]>
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.

Seil -> 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.

Seil -> 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...

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

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.

Seil -> 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

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.

Seil -> 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).

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

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-masked]]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: [email-masked]<mailto:[email-masked]>
Subject: FW: [DMM] Answer on raised questions for the proposed API

Hi Danny,

Any comments?

Regards,
Seil Jeon

From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: [email-masked]<mailto:[email-masked]>
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.

---

From: "Moses, Danny" <[email-masked]>
Date: Sun, 5 Apr 2015 11:22:37 +0000

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-masked]]
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Resent.

Seil

From: Seil Jeon [mailto:[email-masked]]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: [email-masked]'
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-masked]]
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Seil,

Regards,
                /Danny

Hi Danny,

See the inline please.

Seil Jeon

Hi Seil,

> Yes, it's true. Thanks for correction.

> 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.

>> As I said, it could be, but not as general one. The proposed API is useful through the explicit expression for any potential scenarios.

>> My answer was already given in following answer in previous email.

> 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.

>> You can see my answer at the lowest ">>" in this mail.

> 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.

>> 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.

>> 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.

Regards,
                /Danny

Hi Danny,

Any comments?

Regards,
Seil Jeon

Hi,

Regards,

Seil Jeon

---

From: Seil Jeon <[email-masked]>
Date: Sun, 5 Apr 2015 19:42:18 +0100

I have been experiencing a mail posting problem on the list. It is
forwarded with a different mail account.

@Danny, Sorry if you got multiple mails.

Regards,
Seil Jeon

On Sun, Apr 5, 2015 at 7:30 PM, Seil Jeon <[email-masked]> wrote:

> Hi Danny,
>
>
>
> Meeting is always good, even with you by f-to-f. But in the discussion,
> the main issue is whether we will allow the default source address
> selection rules defined in RFC6724 for selecting a Sustained IP address
> among several ones or fundamentally block them for a specific reason raised
> by a DMM need. The latter approach is not reasonable no matter how I try to
> think of.it.
>
> If an application has the specific preference of a newly obtained
> Sustained IP address, it uses the proposed API.
>
>
>
> Regards.
>
> Seil
>
> On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny <[email-masked]>
> wrote:
>
>>  Hi Seil,
>>
>>
>>
>> By now we have been discussing this for quite some time and clearly we
>> did not succeed in convincing each other.
>>
>> I suggest we try again when we have a chance to meet face to face.
>> Meanwhile, let's listen to what other people have to say on this matter.
>>
>>
>>
>> Regards,
>>
>>                 /Danny
>>
>>
>>
>> *From:* Seil Jeon [mailto:[email-masked]]
>> *Sent:* Sunday, April 05, 2015 01:16
>> *To:* Moses, Danny
>> *Cc:* [email-masked]
>> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Resent.
>>
>>
>>
>> Seil
>>
>>
>>
>> *From:* Seil Jeon [mailto:[email-masked] <[email-masked]>]
>> *Sent:* Saturday, April 04, 2015 1:35 PM
>> *To:* 'Moses, Danny'
>> *Cc:* [email-masked]'
>> *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-masked]
>> <[email-masked]>]
>> *Sent:* Thursday, April 02, 2015 2:16 PM
>> *To:* Seil Jeon
>> *Cc:* [email-masked]
>> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Hi Seil,
>>
>>
>>
>> *From:* Seil Jeon [mailto:[email-masked] <[email-masked]>]
>> *Sent:* Tuesday, March 31, 2015 15:23
>> *To:* Moses, Danny
>> *Cc:* [email-masked]
>> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Hi Danny,
>>
>>
>>
>> See the inline please.
>>
>>
>>
>>
>>
>> Seil Jeon
>>
>>
>>
>>
>>
>> *From:* Moses, Danny [mailto:[email-masked]
>> <[email-masked]>]
>> *Sent:* Monday, March 30, 2015 4:44 PM
>> *To:* Seil Jeon
>> *Cc:* [email-masked]
>> *Subject:* RE: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Hi Seil,
>>
>>
>>
>> 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.
>>
>>
>>
>> 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
>>
>>
>>
>> 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.
>>
>>
>>
>> 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)
>>
>>
>>
>> IP Stack action: Since SustainedIPAddressNeeded  is not set, complete the
>> API action and associate the marked Sustained IP address with that port
>> (app)
>>
>>
>>
>> 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)
>>
>>
>>
>> *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.
>>
>>
>>
>> *From:* Seil Jeon [mailto:[email-masked] <[email-masked]>]
>> *Sent:* Monday, March 30, 2015 17:08
>> *To:* Moses, Danny
>> *Cc:* [email-masked]
>> *Subject:* FW: [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Hi Danny,
>>
>>
>>
>> Any comments?
>>
>>
>>
>> Regards,
>>
>> Seil Jeon
>>
>>
>>
>>
>>
>> *From:* dmm [mailto:[email-masked] <[email-masked]>] *On
>> Behalf Of *Seil Jeon
>> *Sent:* Thursday, March 26, 2015 8:08 PM
>> *To:* [email-masked]
>> *Subject:* [DMM] Answer on raised questions for the proposed API
>>
>>
>>
>> Hi,
>>
>>
>>
>> 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?
>>
>>
>>
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>

---

From: "Seil Jeon" <[email-masked]>
Date: Sun, 5 Apr 2015 15:08:16 +0100

Hi Danny,

Meeting is always good, even with you by f-to-f. But in the discussion, the
main issue is whether we will allow the default source address selection
rules defined in RFC6724 for selecting a Sustained IP address among several
ones or fundamentally block them for a specific reason raised by a DMM need.
The latter approach is not reasonable no matter how I try to think of.it.

If an application has the specific preference of a newly obtained Sustained
IP address, it uses the proposed API.

Regards.

Seil

From: Moses, Danny [mailto:[email-masked]] 
Sent: Sunday, April 05, 2015 12:23 PM
To: Seil Jeon
Cc: [email-masked]
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.

Regards,

                /Danny

Resent.

Seil

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-masked]>
mailto:[email-masked]] 
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Seil,

Regards,

                /Danny

From: Seil Jeon [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Danny,

See the inline please.

Seil Jeon 

From: Moses, Danny [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Seil,

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.

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.

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.

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.

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.

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.

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.

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: Set a flag indicating that the currently available
Sustained IP address is not optimized 

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.

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.

>> 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.

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.

>> 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.

>> 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?

 

Regards,

                /Danny

From: Seil Jeon [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc:  <mailto:[email-masked]> [email-masked]
Subject: FW: [DMM] Answer on raised questions for the proposed API

Hi Danny,

Any comments?

Regards,

Seil Jeon

From: dmm [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: [DMM] Answer on raised questions for the proposed API

Hi,

I could also hear some raised comments by Danny and Someone. Here goes
answers to the raised questions.

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?

 

Regards,

Seil Jeon

---

From: "Seil Jeon" <[email-masked]>
Date: Sat, 4 Apr 2015 23:16:12 +0100

Resent.

Seil

Hi Danny,

Regards,

Seil

Hi Seil,

Regards,

                /Danny

Hi Danny,

See the inline please.

Seil Jeon 

Hi Seil,

 

Regards,

                /Danny

Hi Danny,

Any comments?

Regards,

Seil Jeon

Hi,

 

 

Regards,

Seil Jeon

---

From: Seil Jeon <[email-masked]>
Date: Sun, 5 Apr 2015 19:30:53 +0100

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.

Regards.

Seil

On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny <[email-masked]> wrote:

> *From:* Moses, Danny [mailto:[email-masked] <[email-masked]>]
>
> *From:* Moses, Danny [mailto:[email-masked] <[email-masked]>]
>
> IP addresses upon attachment…
>
>
>
> it attaches at a network, regardless of an application’s IP address request.
>
>
>
> >>2
>

---

From: Seil Jeon <[email-masked]>
Date: Sun, 5 Apr 2015 19:41:17 +0100

Regards,
Seil Jeon

---

From: "Seil Jeon" <[email-masked]>
Date: Sat, 4 Apr 2015 13:34:52 +0100

Hi Danny,

Regards,

Seil

Hi Seil,

Regards,

                /Danny

Hi Danny,

See the inline please.

Seil Jeon 

Hi Seil,

 

Regards,

                /Danny

Hi Danny,

Any comments?

Regards,

Seil Jeon

Hi,

 

 

Regards,

Seil Jeon

---

From: "Moses, Danny" <[email-masked]>
Date: Sun, 12 Apr 2015 12:48:52 +0000

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-masked]]
Sent: Sunday, April 05, 2015 17:08
To: Moses, Danny
Cc: [email-masked]
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.
If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API.

Regards.
Seil

Hi Seil,

Regards,
                /Danny

Resent.

Seil

Hi Danny,

Regards,
Seil

Hi Seil,

Regards,
                /Danny

Hi Danny,

See the inline please.

Seil Jeon

Hi Seil,

Regards,
                /Danny

Hi Danny,

Any comments?

Regards,
Seil Jeon

Hi,

Regards,

Seil Jeon

---

From: "Seil Jeon" <[email-masked]>
Date: Sun, 12 Apr 2015 23:03:15 +0100

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-masked]] 
Sent: Sunday, April 12, 2015 1:49 PM
To: Seil Jeon
Cc: [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

We need to take a better look at RFC 6724 and figure out if we need to
update it.

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

Hi Danny,

Regards.

Seil

Hi Seil,

Regards,

                /Danny

Resent.

Seil

Hi Danny,

Regards,

Seil

Hi Seil,

Regards,

                /Danny

Hi Danny,

See the inline please.

Seil Jeon 

Hi Seil,

 

Regards,

                /Danny

Hi Danny,

Any comments?

Regards,

Seil Jeon

Hi,

 

 

Regards,

Seil Jeon

---

From: Dapeng Liu <[email-masked]>
Date: Mon, 13 Apr 2015 20:53:34 +0800

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 写道：

> “I am thinking of two places that might require an update:
> “
> 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.
> 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
>  
>   
> Cc: [email-masked] (mailto:[email-masked])
> 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).
>   
> 3.       Some other approach…
> Cc: [email-masked] (mailto:[email-masked])
> 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).
> Cc: [email-masked] (mailto:[email-masked])
> Cc: [email-masked] (mailto:[email-masked])
> Cc: [email-masked] (mailto:[email-masked])'
> See the inline please. I marked current replies with “>>” and previous replies with “>” for you to catch them easily.
>   
> Regards,
> Seil
>   
>   
> Cc: [email-masked] (mailto:[email-masked])
> Cc: [email-masked] (mailto:[email-masked])
> Cc: [email-masked] (mailto:[email-masked])
> 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…
>   
> 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
>   
> 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…
>   
> >> 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.
>   
> Cc: [email-masked] (mailto:[email-masked])
> To: [email-masked] (mailto:[email-masked])
> 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?
> [email-masked] (mailto:[email-masked])

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 13 Apr 2015 13:21:43 +0000

What is simpler. Can you be more specific? What are you comparing?

Thanks,
                /Danny

From: Dapeng Liu [mailto:[email-masked]]
Sent: Monday, April 13, 2015 15:54
To: Seil Jeon
Cc: Moses, Danny; [email-masked]
Subject: 回复： [DMM] Answer on raised questions for the proposed API

Hello Seil, Danny：

Is it the similar idea?

--
Dapeng Liu

Hi Danny,

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.

“

Best Regards,

Seil Jeon

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.

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…

Regards,

                /Danny

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>.

Regards.

Seil

Hi Seil,

Regards,

                /Danny

Resent.

Seil

From: Seil Jeon [mailto:[email-masked]]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Danny,

Regards,

Seil

Hi Seil,

Regards,

                /Danny

Hi Danny,

See the inline please.

Seil Jeon

Hi Seil,

Regards,

                /Danny

Hi Danny,

Any comments?

Regards,

Seil Jeon

Hi,

Regards,

Seil Jeon

[email-masked]<mailto:[email-masked]>

---

From: Dapeng Liu <[email-masked]>
Date: Mon, 13 Apr 2015 21:27:43 +0800

> What is simpler. Can you be more specific? What are you comparing?

“similar" not “simpler”.

Regards,
Dapeng Liu
  
> Cc: Moses, Danny; [email-masked] (mailto:[email-masked])

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 13 Apr 2015 13:31:37 +0000

Again – what exactly are you comparing? Please be more specific.

From: Dapeng Liu [mailto:[email-masked]]
Sent: Monday, April 13, 2015 16:28
To: Moses, Danny
Cc: Seil Jeon; [email-masked]
Subject: 回复： [DMM] Answer on raised questions for the proposed API

Regards,
Dapeng Liu

Thanks,

                /Danny

From: Dapeng Liu [mailto:[email-masked]]
Sent: Monday, April 13, 2015 15:54
To: Seil Jeon
Cc: Moses, Danny; [email-masked]<mailto:[email-masked]>
Subject: 回复： [DMM] Answer on raised questions for the proposed API

Hello Seil, Danny：

Is it the similar idea?

--

Dapeng Liu

Hi Danny,

“

Best Regards,

Seil Jeon

Some other approach…

Regards,

                /Danny

Hi Danny,

Regards.

Seil

Hi Seil,

Regards,

                /Danny

Resent.

Seil

Hi Danny,

Regards,

Seil

Hi Seil,

Regards,

                /Danny

Hi Danny,

See the inline please.

Seil Jeon

Hi Seil,

Regards,

                /Danny

Hi Danny,

Any comments?

Regards,

Seil Jeon

Hi,

Regards,

Seil Jeon

dmm mailing list

---

From: Dapeng Liu <[email-masked]>
Date: Mon, 13 Apr 2015 21:46:52 +0800

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:

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 写道：

> Cc: Seil Jeon; [email-masked] (mailto:[email-masked])

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 13 Apr 2015 15:02:11 +0100

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.

---------

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:[email-masked]] 
Sent: Monday, April 13, 2015 2:47 PM
To: Moses, Danny
Cc: Seil Jeon; [email-masked]
Subject: 回复： [DMM] Answer on raised questions for the proposed API

Hi Danny, 

 <http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00#section-3.1> 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> ].

IPV6_PREFER_SRC_LOCAL_HNP  /* Prefer a local home prefix */
IPV6_PREFER_SRC_REMOTE_HNP /* Prefer a remote home prefix */

Regards,

-- 

Dapeng Liu

 

“similar" not “simpler”.

Regards,

Dapeng Liu

Thanks,

                /Danny

Hello Seil, Danny： 

Is it the similar idea?

-- 

Dapeng Liu

Hi Danny,

“

 

Best Regards,

Seil Jeon

 

Some other approach…

Regards,

                /Danny

Hi Danny,

Regards.

Seil

Hi Seil,

Regards,

                /Danny

Resent.

Seil

Hi Danny,

Regards,

Seil

From: Moses, Danny [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Seil,

Regards,

                /Danny

Hi Danny,

See the inline please.

Seil Jeon 

From: Moses, Danny [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Seil,

 

Regards,

                /Danny

Hi Danny,

Any comments?

Regards,

Seil Jeon

From: dmm [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: [DMM] Answer on raised questions for the proposed API

Hi,

 

 

Regards,

Seil Jeon

dmm mailing list

[email-masked]

---

From: Dapeng Liu <[email-masked]>
Date: Tue, 14 Apr 2015 00:02:05 +0800

Hi Seil,

> 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

> 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
>   
>    This flag is proposed to be added in RFC5014 (http://tools.ietf.org/html/rfc5014), and aims to express
>    address defined in [draft-yegin-dmm-ondemand-mobility (http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility)]. It is in
>    API for source address selection [RFC5014 (http://tools.ietf.org/html/rfc5014)].
>  
>   
>  
>   
>