[Netext] next steps for netext

sgundave at cisco.com (Sri Gundavelli) Mon, 06 April 2009 17:05 UTC

From: "sgundave at cisco.com"
Date: Mon, 06 Apr 2009 10:05:26 -0700
Subject: [Netext] next steps for netext
In-Reply-To: <C6006CE9.C845%hesham@elevatemobile.com>
References: <C6006CE9.C845%hesham@elevatemobile.com>
Message-ID: <Pine.GSO.4.63.0904060958130.2863@sgundave-sb100.cisco.com>

On Tue, 7 Apr 2009, Hesham Soliman wrote:

>
>>
>> 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 think you're distinguishing between modified and unmodified based on
> whether the modification affects IETF protocols or not. That's fine, but for

Yes. And the reason: There is no such sacred host stack which tells
me what applications I should expect in a "unmodified" host. There
is no such reference. If I install Fedora, XP, Mac OS/X, each of these
hosts come with a different tool set and drivers. But, they all comply
to IETF specs and thats what we should ensure. So, the distinction is
based on what specs our protocol extensions can potentially modify or
if its involved in mobility signaling.

Regards
Sri







> those that did not attend the BoF, our conclusions were that you will either
> end up modifying the host (i.e. Adding new SW) and adding new signalling on
> L2 to handle the multihoming cases, or you can stick with MIP.
> My opinion, and at least half the room's was that this is not a good way to
> go and that it's better to stick with MIP instead of relying on a solution
> that will:
> - work on some L2s and not others,
> - Require additional SW and config on the host which is not done anywhere
> today, and
> - Require L2 signalling which is out of our scope in IETF
>
> This is why I think we should stick with the charter that Jari sent.
>
>
> Hesham
>
>>
>> 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
>
>
>