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