[Netext] next steps for netext

We should take RFC4831 as reference doc, which is the design goals document,
not RFC4830, as it's the PS. It says what is acceptable, in my 
understanding. Referring
to section 3.7, which is about Support for Unmodified Hosts, it first 
says 'Support' for
unmodified hosts. That's what RFC5213 does. It does not exclude modified 
hosts.
More important, the same section says: "Note that this goal does NOT 
mean that the
mobile node has no software at all associated with mobility."... That 
looks pretty clear.

In my opinion, important is that unmodified hosts are supported, which 
is a requirement
we meet. To support enhanced use cases, some supporting software seems to be
acceptable in my opinion and obviously also according to RFC4831. We should
distinguish modification for mobility management, which is not what we 
want to do,
and enabling local functions, such as the use of multiple interfaces, 
where you have
to add routes, configure interfaces etc. to enable the use case.

marco

Hesham Soliman schrieb:
>   
>>> => 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
>>>>         
>>>       
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   