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

My point is that this is an issue *between different systems*. Those other SDOs are going to use PMIP for *inter-system* handovers, and since this goes beyond the scope of the single SDO, I think that IETF is a proper place to deal with this.

>From the discussion we're having it seems that the analysis document exploring the PMIPv6 in the context of the inter-access mobility seems like a worthwile effort. If PMIP6 in this context is found to be harmful to the general Internet, then IMO we should have an IETF document stating this.

domagoj

> -----Original Message-----
> From: ext George Tsirtsis [mailto:tsirtsis at googlemail.com] 
> Sent: 07. travanj 2009 13:27
> To: Domagoj Premec
> Cc: ext Hesham Soliman; Marco Liebsch; 
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Keep missing the point .. Re: [Netext] next steps for netext
> 
> Folks,
> 
> What people keep missing is that 3GPP, 3GPP2, WiMax etc, are 
> all PROPRIETARY systems as far as the IETF is concerned. The 
> IETF is tasked with making sure that the Internet as a whole 
> holds together.
> The IETF should only standardise protocols/tools requested by 
> SDOs if they do not cause harm to the general Internet. This 
> is paramount for the long term sustainability of the Internet.
> 
> Independently from "architectural" viewpoints, it is 
> perfectly reasonable for a given SDO to decide to implement a 
> given technology (e.g., PMIP) in their CLOSED System. PMIP 
> for example can work in the context of 3GPP (as GTP did for 
> many years) since they define a vertical system, from PHY and 
> LINK layers, to Network and even Application layers. In that 
> case, they are free to, for example, implement whatever Link 
> Layer triggers are necessary to make PMIP work in their system.
> 
> It is another thing altogether, however, for the IETF to 
> standardise such a technology, when here we do not have 
> control over link layers.
> On the contrary what the IETF and the Internet are based on 
> is an explicit assumption that "any" link layer should work 
> with minimum requirements from the IP layer, all of which are 
> described in host requirements
> 
> What PMIP proponents have been asking the IETF to do is 
> define a technology that will break an RFC4294 host.
> This is simply not acceptable.
> 
> George
> 
> On Tue, Apr 7, 2009 at 11:55 AM, Domagoj Premec 
> <domagoj.premec.ext at nsn.com> wrote:
> > 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. 
> > Such large scale managed networks are the main consumers of 
> PMIP6 so 
> > we shouldn't be ignoring what they're doing. 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
> >
> 