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

George,

Yes, I guess one could look at it from this perspective, too.  I was hoping that IETF would look into the issues first and then come up with an opinion what is the best way to deal with them. It may very well turn out that the conclusion is to address those issues at the link layer, but before that decision is taken I'd like to see an analysis document listing pros and cons of each approach and then recommending the best way to move forward.

Domagoj

> -----Original Message-----
> From: ext George Tsirtsis [mailto:tsirtsis at googlemail.com] 
> Sent: 07. travanj 2009 14:34
> To: Domagoj Premec
> Cc: ext Hesham Soliman; Marco Liebsch; 
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: Keep missing the point .. Re: [Netext] next 
> steps for netext
> 
> Domagoj,
> 
> Its not like this. These SDOs are explicitly bringing 
> specific technologies under their system architecture. So for 
> example 3GPP defines in Rel9 how movement between 3GPP and 
> specific non-3GPP systems might work using MIP and PMIP. 
> Again the point is that they are defining a closed system, 
> with freedom to affect any layer they want and are totally 
> unconcerned with any technologies (e.g. other link layers) 
> that are not explicitly defined in their system. They are 
> also free to force any requirements they want to devices that 
> want to be called 3GPP-compliant.
> 
> George
> 
> On Tue, Apr 7, 2009 at 1:19 PM, Domagoj Premec 
> <domagoj.premec.ext at nsn.com> wrote:
> > 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
> >> >
> >>
> >
> >
> 