[Netext] next steps for netext

The virtual interface is not new.
All operating system should have one, that is loopback interface.

regards,
ryuji

On 2009/04/06, at 12:40, <Basavaraj.Patil at nokia.com> <Basavaraj.Patil at nokia.com 
 > wrote:

>
> Hi Sri,
>
> Obviously everyone has a different view on what constitutes a host  
> change.
> Creating a virtual interface on a host may be supported on some  
> platforms
> and not on others. I don't think there is a debate about whether  
> such an
> interface can be created to handle handovers. But more importantly,  
> does
> such an interface imply that the host is unmodified.
> IMO, the term "Unmodified host" is too vague to have any real value  
> in this
> discussion. You could have a host which is designed for a network  
> which has
> PMIP6 based mobility support and hence implements a virtual  
> interface as a
> default to support intertechnology handovers. Is this not an  
> unmodified
> host? Does "Unmodified host" always imply a Windows or Mac host as  
> shipped
> from the manufacturers in IETF terminology?
> I strongly believe that there are different classes of hosts which  
> have
> different capabilities and default characteristics. We can spend a  
> lot of
> time on trying to define what constitutes an unmodified host in the  
> IETF
> context. But this is not going to really help in any way.
>
> If we can instead agree that in order to support multihoming or
> inter-technology handovers there may be some implications to the  
> host, we
> would make more progress. We are not proposing defining a new  
> protocol per
> se that is needed on the MN to enable handovers or multihoming  
> support.
>
> -Raj
>
>
> On 4/6/09 11:10 AM, "Sri Gundavelli" <sgundave at cisco.com> wrote:
>
>> Hi Raj:
>>
>> Just one comment.
>>
>>
>>
>> On Mon, 6 Apr 2009, Basavaraj.Patil at nokia.com wrote:
>>
>>>
>>> Hi Jari,
>>>
>>> I think the discussion (or argument as you put it) at the BoF was  
>>> useful. It
>>> highlighted the fact that there is a good amount of  
>>> misunderstanding on what
>>> can be done w.r.t multihoming or inter-technology handovers.
>>> There are some aspects of multihoming that can be clearly  
>>> separated, i.e the
>>> flow mobility vs the ability of having a host attached via multiple
>>> interfaces to the same LMA or dynamically establishing additional  
>>> moobility
>>> sessions. We could narrow down aspects of multihoming which could  
>>> fit into
>>> the scope of the charter.
>>> There has been some discussion (online and offline) about the
>>> inter-technology handovers. The intent of the work item within  
>>> Netext is to
>>> clarify host behavior to support such handovers.
>>> There is obviously quite a strong view of making host changes to  
>>> support any
>>> of the features (multihoming or intertechnology handovers). I  
>>> believe that
>>> there will be a class of hosts which will have the capability to  
>>> support
>>> multihoming and support inter-technology handovers. As long as we  
>>> do not
>>> break the PMIP6 RFC (5213), I think it makes sense to specify these
>>> features.
>>
>>> For unmodiified hosts, we can agree that they will not be able to
>>> perform inter-tech handovers or be support any of the multihoming  
>>> scenarios.
>>
>> No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
>> host" can leverage that feature. As we discussed earlier, we have a  
>> major
>> terminology problem, on what is "modified" vs "un modified". If I use
>> Windows SDK and implement a virtual interface, no one can claim the  
>> host
>> is now modified. Its an application, or a configuration such as using
>> bridge ctl utuility in Linux. Its not changing any of the IETF
>> specifications. We also need to revisit this in the context of  
>> connection
>> mgr requirements in both client-based and network-based mobility  
>> models,
>> which is a common requirement, or other intefaces such as MIF, for
>> flow template push to the terminal.
>>
>> I share the same view with respect to all your other comments. We  
>> need
>> to seperate the cases of flow mobility vs basic handoff as allowed in
>> 5213. In the BOF, we discussed mostly flow mobility and not the basic
>> handoff cases supported today in 5213.
>>
>> Sri
>>
>>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext