Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03

From: Alper Yegin <[email-masked]>
Date: Wed, 18 Mar 2015 11:54:10 +0200

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

---

From: <[email-masked]>
Date: Thu, 19 Mar 2015 18:09:00 +0100

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

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

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

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.

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

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!
Best Regards
Dirk

From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Mittwoch, 18. März 2015 10:54
To: [email-masked]
Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03

Hello DMM WG members,

Cheers,

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 19 Mar 2015 20:04:23 +0200

Hello Dirk,

Thanks for the comments.
Please see below.

On Mar 19, 2015, at 7:09 PM, <[email-masked]> wrote:

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

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

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

> Do you refer here to the below mentioned  Socket API-based interface … [RFC5014]?

We are referring to the API we are defining in this I-D. Will clarify in the text.

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

Where should the priority come from? The spec shall state it?

> =>   The mobile host configures a HoA from a centrally-located Home

Thank you!

Alper

---

From: <[email-masked]>
Date: Fri, 20 Mar 2015 11:12:46 +0100

Hi Alper,
Ok, thanks!
Regarding

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-masked]]
Sent: Donnerstag, 19. März 2015 19:04
To: von Hugo, Dirk
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> wrote:

P.4:

Very good idea, will do.

P.5:

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.

P.7:

Thank you!

Alper

Best Regards
Dirk

From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Mittwoch, 18. März 2015 10:54
To: [email-masked]<mailto:[email-masked]>
Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03

Hello DMM WG members,

Cheers,

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 20 Mar 2015 15:53:54 +0200

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-masked]> wrote:

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