[Netext] next steps for netext

> 
> I will now stop discussing 3GPP specific issues in this list, sorry for that
> :-)

=> Please continue to tell us whether 3GPP needs certain function though.
Based on your last email, I don't understand what is the basis for the
claims of 3GPP needing this function. Seems like a baseless claim not backed
by 3GPP.

Hesham

> 
> Gerardo
> 
> 
> 
>> Vijay
>> 
>>> On the WiMAX side, I know there are still open issues (discussed at the last
>> 3GPP SA2 meeting) to make a handover between 3GPP and WiMAX with PMIPv6
>> working.
>>> 
>>>> Such
>>>> large scale managed networks are the main consumers of PMIP6 so we
>> shouldn't
>>>> be ignoring what they're doing.
>>> 
>>> This is mainly true for intra-technology mobility - and note that I am
>> considering LTE-eHRPD intra-technology here as they are homogeneous from a
>> link layer point of view.
>>> 
>>> Gerardo
>>> 
>>>> Saying to use MIP for inter-access
>>>> handovers/multihoming is not helping as they have really set their mind on
>>>> using PMIP6 and they're already doing this. Without going into the
>> reasoning
>>>> behind such a decision, the fact is that PMIP6, as defined in RFC 5213, has
>>>> issues with inter-access handovers. I think it is better to fix those PMIP6
>>>> issues in the IETF then to let each SDO come up with their own way of
>>>> dealing with this.
>>>> 
>>>> domagoj
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: netext-bounces at mail.mobileip.jp
>>>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
>>>>> Hesham Soliman
>>>>> Sent: 07. travanj 2009 11:14
>>>>> To: Marco Liebsch
>>>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>>>> Subject: Re: [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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
> 