[Netext] next steps for netext

Hi Domagoj,

A couple of clarifications below.

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Domagoj Premec
> Sent: Tuesday, April 07, 2009 3:56 AM
> To: 'ext Hesham Soliman'; 'Marco Liebsch'
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] next steps for netext
> 
> Hi Hesham, all,
> 
> > 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...
> >
> 
> Both 3GPP and WiMAX adopted PMIP6 as means for inter-access handover. 

3GPP allows both PMIPv6 and DSMIPv6 for inter-access handover. PMIPv6 is used for LTE-eHRPD handovers and 3GPP2 designed a new link layer for eHRPD exactly because that was needed for PMIPv6. For example 3G-WLAN inter-system handover is only specified for DSMIPv6 in 3GPP. So let's be clear and stop claiming 3GPP needs PMIPv6 extensions.

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