[Netext] next steps for netext

Hi Hesham,

On 4/6/09 10:37 AM, "ext Hesham Soliman" <hesham at elevatemobile.com> 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
> 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

We can discuss what implies host changes and why this is such a big deal
anyway. But I don't think that half the room was in agreement as such. At
least from the count of hands raised for the question about whether we
should work on multihoming and intertech handovers it was about 18-9 (in
favor). 

> 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,

We have no ability to specify changes to L2 anyway. However if some L2s do
have such capability, why would we not specify how multihoming would work in
such scenarios.

> - Require additional SW and config on the host which is not done anywhere
> today, and

Why is there as much of a concern about additional SW or config? After all
everything (or most of it anyway) that we do in the IETF requires
configurations, protocol changes, changes to SW etc. There is nothing unique
about this. 

> - Require L2 signalling which is out of our scope in IETF

Agree. We cannot do anything about L2s. But we could specify (informatively)
what L2 capabilities would enable these features if that is the conclusion
that we arrive at.

-Raj

> 
> 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
> 
> 