[Netext] next steps for netext

Hi Gerardo, 

> 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).

This is exactly what I would like to avoid. I would prefer using a
solution developed in the IETF rather than something in 3GPP. 

Vijay

> 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
> > >
> > 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 