[Netext] next steps for netext

teemu.savolainen at nokia.com (teemu.savolainen at nokia.com) Wed, 22 April 2009 13:24 UTC

From: "teemu.savolainen at nokia.com"
Date: Wed, 22 Apr 2009 15:24:28 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <Pine.GSO.4.63.0904151344220.2863@sgundave-sb100.cisco.com>
References: <C5FF8EA2.2636C%basavaraj.patil@nokia.com> <Pine.GSO.4.63.0904060903000.22326@irp-view13.cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27F29D55A8@NOK-EUMSG-01.mgdnok.nokia.com> <Pine.GSO.4.63.0904061006170.2863@sgundave-sb100.cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27F29D570E@NOK-EUMSG-01.mgdnok.nokia.com> <Pine.GSO.4.63.0904092110110.22521@irp-view13.cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27F2AB3C55@NOK-EUMSG-01.mgdnok.nokia.com> <Pine.GSO.4.63.0904151344220.2863@sgundave-sb100.cisco.com>
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27F2BC8C48@NOK-EUMSG-01.mgdnok.nokia.com>

Hi Sri,

Sorry for even longer delay. I believe we are in sync, so no other comments. Would the "We can always state our requirements on the host.." take a form of Informational/BCP document?

Best regards,

	Teemu 

>-----Original Message-----
>From: ext Sri Gundavelli [mailto:sgundave at cisco.com] 
>Sent: 16 April, 2009 00:14
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Cc: Patil Basavaraj (Nokia-D/Dallas); netext at mail.mobileip.jp
>Subject: RE: [Netext] next steps for netext
>
>Hi Teemu,
>
>Sorry for the delayed response. Please see inline.
>
>>
>> There are many OS'es, some of which are proprietary and/or 
>used in embedded and/or strongly controlled devices - in such 
>cases it may not be possible just to run a tool or just 
>install application to do the trick even if the device is 
>based on open OS (and especially not by the end users of those 
>systems). These kinds of devices are pretty common in some 
>environments where PMIP6 is planned to be used.. Support for 
>PMIP6 based inter-access handovers would definitely be 
>considered as a change that would need to be justified, 
>implemented, and verified.
>>
>
>You make good points. I agree with you and Domagoj that to be 
>able to say we have a complete solution for inter-tech 
>handoffs, there has to be some support from the host. As you 
>earlier put it, the solution has to assume few things on the 
>host, with respect configuration or might require some special 
>application support. But, before we call it a "host change", 
>lets make sure we certainly require changes to 4861 or other 
>IETF specs, as that appears to be the definition of "host 
>change", in the absence of a standard definition of "standard 
>host". We can always state our requirements on the host for 
>supporting  a given feature and move on.
>
>A solution such as a using virtual interface, to most part, 
>allows the host to be able to perform handoffs, between 
>interfaces. Should not be an issue. However, we might still 
>require the following, that may qualify as a "host change", 
>but depends on how the solution is built.
>
>- Handoff hint exchange between the network and the host. Notifying
>   the purpose of a given attachment, handoff vs new attachment.
>
>- For flow management, network and the host being in sync w.r.t to
>   what flows are being moved around.
>
>- Connection Manager, a common component which cant be avoided, CMIP
>   or PMIP.
>
>As you pointed out to your docs, broadly the above 
>requirements should be sufficient. May be MN-AR interface doc 
>would have helped here, but we killed it.
>
>
>> From my perspective the L2 changes are not very feasible approach: 
>> existing L$
>
>Depends on how we build that interface layer. May be an 
>application interface, or some minimal extensions to ND 
>options, need not be
>L2 change.
>
>
>
>
>Regards
>Sri
>
>
>
>
>
>
>
>
>> In the context of IETF - and wider - discussion, I have been 
>concerned about the message I often hear: that PMIP6 would not 
>require host changes for inter-access mobility. The problem is 
>that some actually read that message literally.
>>
>> In 
>http://tools.ietf.org/html/draft-premec-netlmm-intertech-handov
>er-01 we describe at least some of the impacts (with also 
>solution considerations & proposals):
>> - multihoming & handoffs (when the address should be moved from one 
>> access to another, when to ask for different address for different 
>> access, when to have same address on multiple accesses simultanously 
>> and also have mechahisms for flow distribution)
>> - overlapping IPv4 address spaces (how to know if 192.168.0.1 on two 
>> interfaces is logically the same or different address)
>> - different MTUs
>> - zero physical interface situation (i.e. the transition period when 
>> old access goes away and before the new access comes available)
>>
>> From my perspective the L2 changes are not very feasible 
>approach: existing L2s would need to be changed (=very 
>difficult to get done), and future L2 developers would also 
>need to take care of this dependency. It is easier to handle 
>mobility for IP at L3.
>>
>> Some people have been concerned on interoperability, but I 
>don't think that is an issue: the hosts that would not 
>implement suggested host changes (virtual interfaces, possibly 
>required L3 signaling for advanced handoff scenarios) would 
>work just as they do if they don't support client mobile IP 
>either - they simply do not get seamless inter-technology 
>handovers, but will need to manage with application level 
>reconnection/multihoming techniques.
>>
>> Best regards,
>>
>> 	Teemu
>