Re: Comment on Req2 transparency for DMM
Alexandru Petrescu <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
Hello Antony, Thanks for the good work. You just said this is our last chance to suggest change so here is my last try. Currently in draft-ietf-dmm-requirements-02 this Req2 Transparency reads: > REQ2: Transparency to Upper Layers when needed > > DMM solutions MUST provide transparent mobility support above the IP > layer when needed. Such transparency is needed, for example, when, > upon change of point of attachment to the Internet, an application > flow cannot cope with a change in the IP address. Otherwise, support > for maintaining a stable home IP address or prefix during handovers > may be declined. This last 'declined' sounds IMHO as if this 'support' were requested in the first place. But this request assumes maybe a solution is in place (like Mobile IP or so). I'd rather use the word 'impossible', instead of 'declined', and 'is' instead of 'may be'. > Motivation: The motivation of this requirement is to enable more > efficient use of network resources and more efficient routing by not > maintaining context at the mobility anchor when there is no such > need. I agree with the motivation, although it sounds just a bit strange to me. Maybe it is strange to me because I myself assume Mobile IP :-) Maybe another motivation is like this: "it is hardly feasible to modify all applications deployed (see the large number of applications in the Deering's hourglass model [xx]) such that to support change in IP address or prefix above IP layer without restarting the applications during an ongoing flow (e.g. audio call). This motivates to propose changes at a single point which is the IP layer instead (the waist of the hourglass)." Thanks, Alex Le 03/08/2012 19:07, h chan a écrit : > How about the following: > > The DMM solutions MUST provide transparency above the IP layer when > needed. Such transparency is needed, for example, upon change of > point of attachment to the Internet for the application flows that > cannot cope with a change of IP address. Otherwise the support to > maintain a stable home IP address or prefix during handover may be > declined. > > Or > > The DMM solutions MUST enable transparency above the IP layer. Such > transparency is needed, for example, upon change of point of > attachment to the Internet for the application flows that cannot cope > with a change of IP address. Otherwise the support to maintain a > stable home IP address or prefix during handover may be declined. > > H Anthony Chan > > -----Original Message----- From: Alexandru Petrescu > [mailto:[email protected]] Sent: Thursday, August 02, 2012 > 11:39 AM To: h chan Cc: [email protected] Subject: Re: [DMM] Comment on > Req2 transparency for DMM > > H Anthony, > > Yes, this reflects Sri's and my suggestion about removal of MN/MR > qualifier. I agree with the idea of the new text as you put it. > > Then, if I re-read just like that, there still seems to be some > difficulty to my brain to understand: > > Le 01/08/2012 23:35, h chan a écrit : >> The DMM solutions MUST provide transparency above the IP layer >> when needed, such as upon change of point of attachment to the >> Internet, for the application flows that cannot cope with a change >> of IP address. Otherwise the support to maintain a stable home IP >> address or prefix during handover may be declined. > > I don't understand the last phrase - the 'otherwise' relates to the > first MUST? Or to the latter 'cannot'? > > But this may be just nitpicking on the use of language. I agree > with the direction of the idea and thank you for having provided the > modification. > > Alex > >