[Netext] Keep missing the point .. Re: next steps for netext

On 8/04/09 4:41 PM, "Mohana Jeyatharan" <Mohana.Jeyatharan at sg.panasonic.com>
wrote:

> Hi Rajeev and All,
> 
> I like the summary you have put forward here. As you have mentioned and many
> others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
> Currently we have a scenario where the MN MUST use PMIPv6 for mobility
> management for its multiple interfaces. I do not want to quote SDO, but
> 3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or
> s2b(WLAN) interface.

=> If you're going to say "MUST" then yes you must quote that requirement.
If it came from an SDO then please send us a reference to that. Other 3GPP
people don't agree with you and stated that publicly on the list.

Hesham

Then if this MN wants multihoming, flow mobility etc, how
> can we do this? Are we going to run MIP6 ony for multihoimg purpose, on top of
> PMIP being used in corenetwork. Is this a good idea or are we going to do
> major multihoming work in MAG-LMA path and do some minor modifications to MN
> to keep it light weight as far as protocol modification is concerned. The
> second option seems more logical for pure PMIpv6 scenario. Reason is: operator
> may not allov two mobility manamgement protocols running just to achieve
> multihoming and what if the MN does not have MIP6 stack implemented.
> 
> For scenarios where MIP6 is used to handle mobility for all interfaces, then
> client based multihoming given as extensions of MIP6 is excellent. No one can
> deny this. For mixed scenarios such as PMIP and CMIP scenarios involving
> multiple inetrafces, then again probably MIP6 based multihoming may be ideal.
> This is something we need to explore as well.
> 
> But our discussion currently at Netext is, operator decides PMIPv6 for all
> interfaces and what solution do we have for multihoming and flow mobility? I
> think we should think along these lines. Is this PMIPv6 multihoming solution
> identical to MIP6 Multihoming solution. I don't think so. So we need to look
> at some drafts available that handles PMIPv6 multihoming and flow mobility and
> see the changes in UE and some functional modules introduced in architectural
> entities, to understand the differences. If same then no need of any new work.
> If different then need to look at benefits. Can we reduce signaling in MN-AR
> interface, can we make the protocol chnages of a leagcy MN minimal, can we
> reduce core network signaling. All such criteria need to be taken into account
> for comparision.
> 
> Well if the operator does not mind CMIP running over PMIP fine and good.
> But, what if not....
> 
> Thanks.
> BR,
> Mohana
> 
>> -----Original Message-----
>> From: netext-bounces at mail.mobileip.jp [mailto:netext-
>> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
>> Sent: Wednesday, April 08, 2009 7:46 AM
>> To: netext at mail.mobileip.jp
>> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
>> 
>> 
>> 
>> Folks,
>> 
>> Let's step back a bit..It doesn't help to pit one protocol against another
>> like this, especially when they are both developed by us :-)
>> 
>> If the problem is well-understood - i.e., how to selectively move flows
>> across interfaces for MIP, the same problem is being investigated here for
>> PMIP6. Why? With multiple interfaces, there seems to be interest in this
>> (so-called flow mobility). How will this work? We don't know yet, we don't
>> have a standards spec, but there are a few drafts. We are only setting the
>> stage for solution(s).
>> 
>> Given this, we should try to focus on investigating the problem and
>> agreeing on how to go about working on a protocol specification. People
>> already know they could use MIP6 for this. We could re-state it surely,
>> but that cannot be the only approach.
>> 
>> Thanks,
>> 
>> -Rajeev
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
>>> Sent: Tuesday, April 07, 2009 3:27 PM
>>> To: Vijay Devarapalli
>>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
>>> Subject: Re: [Netext] Keep missing the point .. Re: next
>>> steps for netext
>>> 
>>> 
>>> 
>>> 
>>> On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
>>> 
>>>> Hesham Soliman wrote:
>>>>> I don't know which people you're talking about or on which planet
>>>>> this stuff is being deployed.
>>>> 
>>>> Thats easy. Search for "LTE HRPD" at google.com. :)
>>>> 
>>>>> In any case, I'm interested in discussing technical
>>> aspects of this
>>>>> work and I have zero interest in politics and projections.
>>>> 
>>>> But I don't see that. You seem to want to tell people to use Mobile
>>>> IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
>>> 
>>> => I'm not *telling* people to do it, I'm arguing that this
>>> is the best approach. All I'm getting back is "SDOx want
>>> this" and "people want this"
>>> and "the ship has sailed". It's very frustrating to have a
>>> discussion like this instead of showing a real PS.
>>> 
>>>> 
>>>> FWIW, the way I see it, the flow mobility solution for
>>> PMIPv6 does not
>>>> have to be that different from what we have for MIPv6.
>>> Instead of the
>>>> mobile node sending the service selection option (defined
>>> in RFC 5149)
>>>> and flow identification option in the BU, it?s the MAG that
>>> sends this
>>>> information in the PBU. The solution is the same. You tell
>>> the HA or
>>>> the LMA which flow filters to install.
>>>> 
>>>> The solution could be along the lines I wrote in section 3.3 of
>>>> draft-devarapalli-netlmm-multihoming-01.txt (submitted in
>>> Nov 2007).
>>>> It says
>>> 
>>> => If there is a solution to be had I don't care whether it
>>> uses our draft or something new. My point is that making
>>> those decisions in the network just doesn't work. Yes there
>>> bits on the wire that can do anything but the decision to
>>> trigger these actions in the network is flawed. And without
>>> getting into too much detail, before we decide to go one way
>>> or another, I think a technical argument needs to be made
>>> about "why" it's needed and not "how" it might work. This
>>> might sound old-fashioned these days but I find it difficult
>>> to rubber stamp things without understanding why.
>>> This is all I'm going to say about this BoF unless someone
>>> has a PS to discuss.
>>> 
>>> Hesham
>>> 
>>>> 
>>>>     For this scenario to work, the mobile node must be able
>>> to indicate
>>>>     to the attached MAG which flow will be sent over the
>>> attachment to
>>>>     the MAG.  It may do this by indicating the service
>>> identifer during
>>>>     the layer 2 attachment to the MAG.  The service identifier is
>>>>     described in [4].  The MAG, in turn must include the
>>> flow information
>>>>     in the Proxy Binding Update sent to the LMA.  The MAG
>>> may use the
>>>>     Service Selection option [4] in the Proxy Binding
>>> Update to indicate
>>>>     the flow information.  The MAG may also contruct a flow
>>> filter and
>>>>     convey the information in the Proxy Binding Update.
>>> See [3] for more
>>>>     information on carrying flow filters in the proxy
>>> binding update.
>>>> 
>>>>     The LMA processes the Proxy Binding Update from the MAG
>>> and creates a
>>>>     filter based on the flow information.  The flow filters
>>> may be stored
>>>>     in the binding cache entry for the mobile node.
>>>> 
>>>>     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
>>>>          Support", draft-soliman-monami6-flow-binding-04 (work in
>>>>          progress), March 2007.
>>>> 
>>>>     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
>>>>          Selection for Mobile IPv6",
>>> draft-korhonen-mip6-service-04 (work
>>>>          in progress), October 2007.
>>>> 
>>>> [4] got published as RFC 5149.
>>>> 
>>>> Anyway, I don't think we should get into discussing
>>> solutions at this
>>>> point. The above is to just show that the MIPv6 solutions can be
>>>> re-used for PMIPv6. We don't have to re-invent what we have
>>> done in the IETF so far.
>>>> 
>>>> I would prefer that we let the market decide whether they
>>> want to go
>>>> with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
>>> or PMIPv6.
>>>> that would be a political discussion. :)
>>>> 
>>>> Vijay
>>>> 
>>>>> 
>>>>> Hesham
>>>>> 
>>>>> 
>>>>> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
>>>>> 
>>>>>> George, Hesham,
>>>>>> 
>>>>>> I don't see the point in having philosophical discussions
>>> on whether
>>>>>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
>>> point. That
>>>>>> ship has sailed. What we have as a reality is folks deploying
>>>>>> systems with inter access technology handovers with PMIPv6 as the
>>>>>> mobility management protocol. Asking these folks to now
>>> use Mobile
>>>>>> IPv6 does not help anyone, IMHO.
>>>>>> 
>>>>>> Vijay
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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