[Netext] next steps for netext

>> 
>> => 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). 

=> I think the question changed a few times :) The final question (which was
specific to whether people wanted to work with this or not) showed a split
room. 
The host changes are not a big deal but they are mentioned here because they
were one of the very few reasons for using NETLMM in the first place: Host
changes (adding new SW to the host) and signalling from the MN. You can see
them in section 4 of RFC 4830.

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

=> Because we already have a solution that works in all L2s, doesn't require
L2 changes that we don't control and doesn't cause confusing host config
solutions. 

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

=> Sure, but see above and see RFC 4830. These were the reasons for using
PMIP in the first place. We can't have it both ways, or can we? :)

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

=> We can, but I don't know why we should do that when a solution already
exists. Especially when the alternative is inferior in terms of its
applicability.

Hesham

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