Hi Alper, Ok, thanks! Regarding More than one of these flags may be set on the same socket. In that case, an IP address compliant with any one of them shall be selected. TBD: Disallow this case? Since here we have requirements instead of preferences unavailability of the required address type would force configuration of compliant address - but some applications can accept several types (for different planes CP/DP or with different priority). Question is what would be the additional effort for forced configuration vs. gain by 'more optimal' performance? My guess: allow, but introduce priority for selection
Where should the priority come from? The spec shall state it? I think the application should be able to decide on the priority, and the spec includes a corresponding option with values to pick from (for the time being only 3-level priority needed ... unless there should be room for later update with more refined types) Best Regards Dirk From: Alper Yegin [mailto:[email protected]] Sent: Donnerstag, 19. März 2015 19:04 To: von Hugo, Dirk Cc: [email protected] Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 Hello Dirk, Thanks for the comments. Please see below. On Mar 19, 2015, at 7:09 PM, <[email protected]<mailto:[email protected]>> wrote: Dear Alper and co-authors, Thanks for your work! IMO the draft is clearly written and ready for adoption though some questions and comments came to my mind: In the Intro Mobile IP is referenced to both client and Proxy MIP In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], - but in the remaining PMIP functional elements (MAG, LMA) are never mentioned ... silly question: so do you propose to apply the solution only to client MIP based approaches or do you implicitly assume for mobility unaware hosts/devices that the IP stack on MAG is addressed instead? I suggest to add a clarification in the beginning ... API applies to both CMIP and PMIP hosts. We don't mention MAG or LMA, as those details are not related to the "API". P.4: A sustained IP address may be configured and maintained by using access network anchoring, corresponding network anchoring, or some other solution. I suggest to add a reference here (RFC7429 defining Anchoring Function) or explain with "allocating to a mobile node an IP address analogous to CoA at FA in MIP by selecting an anchor router for relaying the traffic" or similar ... Very good idea, will do. P.5: Applications running as servers at a published IP address require a Fixed IP Address. Long-standing applications (e.g., an SSH session) may also require this type of address. Those applications could use a Sustained IP Address, but that can produce sub-optimal results if the mobile host ends up far from the anchor gateway. The latter sentence sounds to me as such sub-optimality will not happen in case of Fixed IP Address - isn't it even worse when the host already starts far from the centrally-located Home Network ...? Right, it can be..... But depending on the deployment, a centralized HA may be in a better position to serve long sessions than an AR at the edge (because of scalability, and also funneling traffic "in&out" may not suit the AR well, as its uplink may not be provisioned with enough capacity). Anyways, we should massage the text, .. will propose something. then the IP stack shall fail the associated socket request. => then the IP stack shall fail to fulfil/meet/comply with the associated socket request. P.6: - Determination of a default address type when an application does not make any explicit indication, whether it already supports the required API or it is just a legacy application. Do you refer here to the below mentioned Socket API-based interface ... [RFC5014]? Otherwise I suggest to add some explanatory words on the required API. We are referring to the API we are defining in this I-D. Will clarify in the text. P.7: More than one of these flags may be set on the same socket. In that case, an IP address compliant with any one of them shall be selected. TBD: Disallow this case? Since here we have requirements instead of preferences unavailability of the required address type would force configuration of compliant address - but some applications can accept several types (for different planes CP/DP or with different priority). Question is what would be the additional effort for forced configuration vs. gain by 'more optimal' performance? My guess: allow, but introduce priority for selection Where should the priority come from? The spec shall state it? In addition few nits detected: P.2: despite the mobile host chaging its point of attachment within the IP => despite the mobile host changing its point of attachment within the IP P.3: session continuity and IP address reachability should be be provided => session continuity and IP address reachability should be provided P.4: The mobile host is configures a HoA from a centrally-located Home => The mobile host configures a HoA from a centrally-located Home Thanks! Thank you! Alper Best Regards Dirk From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin Sent: Mittwoch, 18. März 2015 10:54 To: [email protected]<mailto:[email protected]> Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 Hello DMM WG members, As you remember, WT#1 came to an agreement to propose the following I-D as the baseline for the API piece: http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt We'll be proposing its adoption in Dallas. FYI, and here's your chance to voice any input in advance. Cheers, Alper
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
