Re: Last Call comment on dmm requirements

"Moses, Danny" <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <F0CF5715D3D1884BAC731EA1103AC281027F0202@HASMSX106.ger.corp.intel.com>
I agree that one example of optimizing network overhead is by improving the mobile node's usage of it source IP address and I am sure there are more examples.

So the proposed new requirement is too restrictive.

Having said that, I do not think we should allow functionality that will break if backwards compatibility is not maintained. Only optimizations that are optional.

Regards,
	/Danny

-----Original Message-----
From: Peter McCann [mailto:[email protected]] 
Sent: Monday, July 01, 2013 19:03
To: [email protected]; Moses, Danny
Cc: [email protected]
Subject: RE: [DMM] Last Call comment on dmm requirements

This is not the netlmm working group.  Client modifications are very much in scope.

I think that mobile nodes will at least need to be enhanced with more flexibility about the way they handle assigned addresses.  The scope of mobility for a given address may be limited or it may cost resources to extend the scope too far with network-based means.  The MN must be allowed to monitor its applications' use of IP addresses and release those addresses that are no longer used, and get a new IP address for new application connections.  This does not necessarily involve a new protocol for the MN but is a modification of its usual behavior.

-Pete


Behcet Sarikaya wrote:
> Hi Danny,
> 
> 
> 
> On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny <[email protected]>
> wrote:
> 
> 
> 	Hi,
> 
> 
> 
> 	I am sorry by this requirement sounds to me too generic and limiting.
> What functionality must not be modified? Why?
> 
> 	I am assuming that the motivation might be related to backwards 
> compatibility.
> 
> 
> No. It is related to the protocol being network based. It does not 
> make sense to get MN's help in such a protocol, because otherwise it 
> is no longer network based.
> 
> Network based protocols with MN modification blur the difference 
> between client based and network based protocols.
> 
> So everything becomes client based.
> 
> 
> 
> 	If this is the case, it is already addressed. Furthermore, I do not 
> see a reason why not to enable modifications that may enhance 
> performance or improve user experience as long as they are optional 
> (hence do not violate the backwards compatibility requirement).
> 
> 
> 
> 	Regards,
> 
> 	                /Danny
> 
> 
> 
> 	From: [email protected] [mailto:[email protected]] On Behalf Of 
> Behcet Sarikaya
> 	Sent: Saturday, June 29, 2013 00:35
> 	To: [email protected]
> 	Subject: [DMM] Last Call comment on dmm requirements
> 
> 
> 
> 	Add this requirement:
> 
> 	R. XX. In network based dmm solutions, the mobile node MUST not be 
> modified. No changes on the mobile node behavior can be allowed.
> 
> 
> 	Regards,
> 
> 	Behcet
> 
> 	----------------------------------------------------------------- ----
> 	A member of the Intel Corporation group of companies
> 
> 	This e-mail and any attachments may contain confidential material for
> 	the sole use of the intended recipient(s). Any review or distribution
> 	by others is strictly prohibited. If you are not the intended
> 	recipient, please contact the sender and delete all copies.
>



---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.