[Netext] next steps for netext

3GPP has a study item on this feature. There was no PMIPv6 solutions proposed on any I-D - there is a 3GPP-specific solution proposed for PMIPv6 (based on the policy infrastructure).

3GPP has not decided yet to do any normative work on any of the solutions. 

Gerardo

> -----Original Message-----
> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> Sent: Tuesday, April 07, 2009 2:52 PM
> To: Giaretta, Gerardo
> Cc: Domagoj Premec; 'Marco Liebsch'; netext at mail.mobileip.jp;
> Basavaraj.Patil at nokia.com
> Subject: Re: [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
> >
> 