[Netext] next steps for netext

>> => 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.
>>   
> Yes, a problem statement about an existing solution for network-based
> mobility
> management (PMIPv6) to support advanced use cases.

=> Where is that PS?

  Not the problem of
> existing solutions for localized mobility, as RFC4830 does. I don't
> think NetExt
> aims at turning PMIPv6 into a host-based mobility protocol again.

=> I don't know what the goal is based on the BoF discussion and this
discussion on the list. The reason I don't know that is that no one is
saying:
Here is the state of the art (including BOTH MIP and PMIP) and here is why
they don't work, therefore we need to do something new.
That's what a PS should say. What's being said here is "PMIP doesn't support
advanced cases therefore we need something new", which is completely bogus
because PMIP was not designed to support those cases because we already have
something else for supporting those cases. Hence my reference to 4830...

I'm going to retire from the discussion till someone makes the argument
above. Because I feel that if there is no such argument then the discussion
is not a good use of time.

>> => 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.
>>   
> Nobody talks about adding a piece of client mobility management
> software, such as a
> MIP client, to the mobile. That seems to be a wrong interpretation of
> what NetExt
> wants to do.

=> You're missing the point. Why isn't anybody talking about MIP??? That's
what a PS should say.

Hesham

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