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