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

Hi Behcet,

Well, if MN does not want any advanced features but wants basic IP connectivity while moving, then these MN's can remain. However, if they want
Advanced featrues, then they need chnages. I think the question is the degree. I think this should be very minimal.

I hope you agree.

BR,
Mohana

________________________________________
From: Behcet Sarikaya [mailto:behcetsarikaya at yahoo.com] 
Sent: Wednesday, April 08, 2009 10:20 PM
To: Mohana Jeyatharan; Koodli, Rajeev; netext at mail.mobileip.jp
Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext

Hi Mohana,
? Pls find a little comment below.
Regards,
?
Behcet
________________________________________
From: Mohana Jeyatharan <Mohana.Jeyatharan at sg.panasonic.com>
To: "Koodli, Rajeev" <rkoodli at starentnetworks.com>; netext at mail.mobileip.jp
Sent: Wednesday, April 8, 2009 12:41:49 AM
Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext

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. 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. 
?
[behcet] Then this simple question comes to one's mind: what if MN does not have these some minor modifications to MN??you mentioned above? 
How do we interoperate these MNs?

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