Hi, I have fixed the two typos you indicated in the previous emails. Please see my embedded reply. I am waiting for you reply on my question below regarding the source code example comment before uploading rev 10.
Thanks for the useful comments, Danny From: Dave Dolson [mailto:[email protected]] Sent: Thursday, December 08, 2016 21:00 To: Moses, Danny <[email protected]> Cc: [email protected]; [email protected] Subject: WGLC for draft-ietf-dmm-ondemand-mobility-08 -- I'm just catching up on the recent drafts, so apologies if this has been covered... 1. It seems like RFC 6724 will need to be updated by dmm-ondemand-mobility. I'm unclear on how the algorithm should be modified. Has anyone worked this out? My sense is that Rule 4 needs to be modified to consider the new flags. Either this document should spell out the new algorithm, or we plan for RFC6724bis. DM>> This is probably true. I am adding an RFC6724 fix to my ToDo list which is quite long, so I hope someone else Takes this work. If not, let's do this together in the future. 2. Regarding the language about IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA with legacy applications, I think it would be right to continue to support these. PREFER_SRC_HOME could ask the network for FIXED, but automatically fall back to another address. I think this is useful so that the application doesn't have to handle EAI_REQUIREDIPNOTSUPPORTED and try again. (This comment goes back to point 1.) DM>> First, for backwards compatibility, we must support these flags and the draft does not suggest otherwise. I prefer not to mix the functionality of the legacy flags - IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA with the new flags defined in the OnDemand draft. The main reason is that the former flags are related to a MIP environment were the MN terminates the tunnel, while the OnDemand flags are related to a proxy MIP environment (PMIP or GTP - for example) were the MN is not aware of the mobility support. 3. I don't understand the need for IPV6_REQUIRE_NON-PERSISTENT_IP as an explicit flag. I would think it works better to provide this behavior if neither of the other flags are set. Literally it says, "I will not accept a FIXED or SESSION_LASTING IP". Is that useful? It can be provided, but I don't think any app would use it. Maybe just for testing the network? DM>> Actually, this flag is one of the main motivation for this work. It enables the application to explicitly request the network not to create a tunnel for the IP session and avoid the unnecessary overhead associated with the tunnel. Opening a socket without using any of these flags means that the application does not have a preference to the type of service it receives from the network and leave the decision of choosing the type of service to either the IP stack in the MN or the network. It is important to enable the application to explicitly request a non-persistent service (and to receive an error if this service is not supported). 4. Consider an appendix showing source code for clients and servers with different requirements. E.g., I believe that the setsockopt() needs to be done after socket() but before bind(), connect(), send(), sendmsg(), sendmmsg(), sendto(),etc. (After any packets are sent is too late.) I think it would be useful to show this recipe. DM>> Your description is correct. I am wondering what is better, to add a short paragraph describing when setsockopt() should be used (as you described) or adding source code example. I prefer the text to be short and clear, and whenever we add source code examples we either end up with a long example, or limit ourselves to some obvious example that does not address all alternatives. Will adding the clarification that you pointed out be sufficient? 5. Are there new errors from bind(), listen() or connect(), etc.? E.g., socket option is FIXED, but user explicitly specified a COA address to bind to? DM>> We considered this, but decided not to go there since we would have to think of all the possible erroneous combination and programmer might do. We therefore, decided to clearly state that such behavior would be ignored. David Dolson Senior Software Architect, Sandvine Inc. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
