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