[Netext] next steps for netext

On 7/04/09 6:38 PM, "Marco Liebsch" <marco.liebsch at nw.neclab.eu> wrote:

> We should take RFC4831 as reference doc, which is the design goals document,
> not RFC4830, as it's the PS.

=> We're discussing a problem statement for the BoF, so 4830 is quite
appropriate as a reference for why people wanted PMIP in the first place.

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.

=> Did you read section 4? Here is an example:
" 1) Interoperable IP-level protocols that require changes to the
      mobile node's IP stack and handle localized mobility management as
      a service provided to the mobile node by the access network.

   2) Link specific or proprietary protocols that handle localized
      mobility for any mobile node but only for a specific type of link
      layer, for example, 802.11 [6].

   The dedicated localized mobility management IETF protocols for
   Solution 1 are not yet widely deployed, but work continues on
   standardization.  Some Mobile IPv4 deployments use localized mobility
   management.  For Solution 1, the following are specific problems:

   1) The host stack software requirement limits broad usage even if the
      modifications are small.  The success of WLAN switches indicates
      that network operators and users prefer no host stack software
      modifications.  This preference is independent of the lack of
      widespread Mobile IPv4 deployment, since it is much easier to
      deploy and use the network."

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

=> Yes, additional software like the existing MIP. I don't understand the
motivation for creating something new. I've detailed this in my previous
emails and the points remain unanswered.

Hesham

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