[Netext] next steps for netext

Hi, Hesham and Marco:
Please see the comments inline!
-Qin
>  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.
[Qin]=>
The scope and requirement of localized routing is very clear to me in the new charter. The motivation is to enrich the basic proxy mobile
IPv6 service with some additional feature and enable wide deployment and scalability.
The state of the art should refer to the section 6.10.3 of "local routing" in the RFC5213. Actually the concept of local routing has already be widely utilized in the
real practice, e.g., in the 3G cell network. Of cource this concept also works for the proxy mobile IPv6. That is what RFC5213 specifies in the section 6.10.3. However it has its limitation on the scenario, it restricts to be used in the intra-MAG mobility scenario. To enlarge the scalabilty of local routing(e.g., inter-MAG mobility or intra-LMA mobility, inter-LMA mobility), the PS document is developed to tackle this issues.

On the other hand, leaving the local routing issue aside, there are quite a lot of works on routing optimization in the netlmm working group. However they have the same difficulty, i.e., not applicable for inter-domain mobility. That's why local routing should fous on intra-domain mobility. So local routing can be viewed as  optimized pmip6-based approaches for the intra-domain moblity. The existing works includes:
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00. 
> http://tools.ietf.org/html/draft-qin-netlmm-pmipro-00
As regarding the last draft, we have updated it into new draft and posted to the IETF repository. The URL for this internet draft is:
http://tools.ietf.org/html/draft-wu-netext-local-ro-00
With this existing works, it can better the PS document for local routing and has a clear understanding what the PS document want to solve.
>
>> 
>> 
>>> 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
>>>>>   
>>>>>       
>>>>     
>>> 
>>> 
>>>   
>> 
>> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>