Hi Lorenzo,
You can find my comments inline. Regards, Seil Jeon From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Wednesday, December 07, 2016 1:01 PM To: Seil Jeon <seilj...@gmail.com> Cc: dmm@ietf.org; Moses, Danny <danny.mo...@intel.com>; Peter McCann <peter.mcc...@huawei.com>; john.kaippallima...@huawei.com Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Seil Jeon, I'm not sure I understand. The draft implies that IPV6_REQUIRE_SRC_ON_NET forces the device to talk to the network even if it already has a prefix from the current network. Why do this? No. it doesn’t force to the IP stack. It is just telling what additional requirement of the application to the IP stack. If the stack has it from the current serving network, the best-matched one will be used. Or, it will request a new one. Suppose the following sequence of events occurs. 1. The device has a mobile (e.g., session-lasting) IPv6 prefix only. 2. The device moves to a new attachment point and its only prefix (and only IP addresses) are now subject to suboptimal latency. 3. An application wants to use an IPv6 address from the local network, in order to minimize latency. 4. The device does not have a local prefix assigned by the local network, so it gets a local prefix from the network. This takes 1-2 seconds. 5. 100ms later, another application wants to use an IPv6 address from the local network. At point 5, it is much more faster for the host to say, "I already have a prefix from the local network, I will just create a new address from that prefix" than to talk to the network. I’m not sure what local prefix you mean. I don’t know what default policy to assign an IPv6 prefix to the host in your scenario. But if you mean the local prefix as session-lasting IP prefix, once the IP stack gets the prefix at step 4, it will not need step 5. In step 4, the local prefix could be non-persistent IP address, not session-lasting IP address. And suppose one or more session-lasting IP addresses are already existing in the stack. Then, a new application requiring on-net property will need a session-lasting IP prefix from the current serving network. The purpose of the on-net property is to help an application get a prefix assigned from the current serving network. Is IPV6_REQUIRE_SRC_ON_NET defined because at step 2, the device does not know it has moved? This draft doesn’t talk about any mobility protocol, but just dealing with how application’s IP address requirement can be delivered to the IP stack. The on-net API also belongs to the same goal. Regards, Lorenzo On Wed, Dec 7, 2016 at 12:42 PM, Seil Jeon <seilj...@gmail.com <mailto:seilj...@gmail.com> > wrote: Hi Lorenzo, Please see inline. Regards, Seil Jeon From: dmm [mailto:dmm-boun...@ietf.org <mailto:dmm-boun...@ietf.org> ] On Behalf Of Lorenzo Colitti Sent: Wednesday, December 07, 2016 12:20 AM To: Moses, Danny <danny.mo...@intel.com <mailto:danny.mo...@intel.com> > Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org <mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org> ; Peter McCann <peter.mcc...@huawei.com <mailto:peter.mcc...@huawei.com> >; dmm@ietf.org <mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Danny, I don't think assigning addresses vs. assigning prefixes is a question only of mechanism. For example, consider the IPV6_REQUIRE_SRC_ON_NET flag. If the network is following IP addressing best practices, I don't see a need for it. If a host already has an IPv6 address of the desired type, what's the point of sending a request to the network to obtain one? The reason is well described in <https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-05> https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-05 like following Acquiring a new session-lasting IP address may take some time (due to the exchange with the network) while using an existing one is instantaneous. On the other hand, using the existing one might yield less optimal routing. For example, the use of the IP address with an existing one configured might provide a suboptimal routing path as a result of a handover. This situation might not be preferred by newly initiated applications because the application incurs the costs of IP mobility even though the MN has not moved from the current serving network. Eventually, the new session is served by a remote IP mobility anchor with mobility management functions, though the MN has not moved yet. Is it so that the requesting app can obtain a new IP address with the desired properties, unique to that particular socket? But if so, the host should just create a new address for that socket, with the desired properties. The network should not be requiring that the host ask for individual IP addresses; it should be allowing the host to form more IP addresses without requesting them. In any case: since the socket options defined in this draft are IPv6-only, it only needs to concern itself with IPv6, and we're really only left with one case: a prefix. If so, how about the following? “By issuing a request to the network” you pointed out in the previous mails has been described as the on demand nature for a long time in [I-D. draft-ietf-dmm-ondemand-mobility]. If it is an issue INDEED, it needs to be revised not with individual address but with prefix. Would it be better? Second, from your text, the reason to use the proposed API is not to use the address based on the same prefix. “Creating a new one from an existing prefix of the desired type” is away from the intention. ==== When the IP stack is required to use a source IP address of a specific type, it can perform one of the following: it can use an existing address with the desired type (if it has one), or it can create a new one from an existing prefix of the desired type. If the host does not already have an IPv6 prefix of the specific type, it can request one from the network. Using an address from an existing prefix is faster but might yield a less optimal route (if a hand-off event occurred since its configuration), on the other hand, acquiring a new IP prefix from the network may take some time (due to signaling exchange with the network) and may fail due to network policies. ==== Cheers, Lorenzo On Tue, Dec 6, 2016 at 9:27 PM, Moses, Danny <danny.mo...@intel.com <mailto:danny.mo...@intel.com> > wrote: Firstly, I agree that the only two examples of ‘resource’ type that may result with a creation of a source IP address are (i) an IP address and (ii) an IP prefix. I cannot think of any other magic, but perhaps some else can… I am trying to avoid the term ‘prefix’ because it is not directly related to the Socket interface and I am trying to separate the definitions related to the Socket interface from the definitions related to the interaction between the MN and network. If I mention prefixes, I will have to explain that the network may allocate IP addresses or IP sockets and that in cellular networks the recommended mechanism is to allocate /64 prefixes… I do not want to get into these details because they are not helpful for Socket API users. However, I do intend to get into these details (and refer to the recommendation of RFC 7934) in the drafts that describe the extensions required to convey the IP service type between the IP stack in the MN and the network. From: Lorenzo Colitti [mailto: <mailto:lore...@google.com> lore...@google.com] Sent: Tuesday, December 06, 2016 13:43 To: Moses, Danny < <mailto:danny.mo...@intel.com> danny.mo...@intel.com> Cc: Peter McCann < <mailto:peter.mcc...@huawei.com> peter.mcc...@huawei.com>; jouni.nospam < <mailto:jouni.nos...@gmail.com> jouni.nos...@gmail.com>; <mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org> draft-ietf-dmm-ondemand-mobil...@ietf.org; <mailto:dmm@ietf.org> dmm@ietf.org Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 On Mon, Dec 5, 2016 at 9:50 AM, Moses, Danny <danny.mo...@intel.com <mailto:danny.mo...@intel.com> > wrote: I think it is important to describe that application developer can influence the type of service the IP session is receiving, while being vague about the mechanism of address allocation. Since you are concern with the draft using the term ‘address’ and I am concern with using the term ‘prefix’, I tried using the term ‘network resources’. Yes, it is vague, but that is the intention. Ok, but what other type of resource can result in the MN being able to use an IP address? It seems to me that only an IP address or a prefix will qualify. And if allocating address on request is recommended, then that only leaves a prefix. If there are other types of resource that I'm missing, then "resource" might be OK, as long as it has appropriate examples. But if the only two options are "address" and "prefix" and "address" is not recommended, then saying "resource" is at best unhelpful and at worst misleading. Can you explain why you are concerned with using the term "prefix"? --------------------------------------------------------------------- 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
