Hi Dirk, I think we need to look at some example scenarios to see how common this case would be. If this additional logic is used rarely, then it may not be worth burdening the API with it.
Alper On Mar 20, 2015, at 12:12 PM, <[email protected]> wrote: > 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]> 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] > 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
