Subject: RE: [mobile-ip] Draft on Mobile IP Architecture and Reorg

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 28 Feb 2003 19:26:15 +0100

James, 

Actually I'm still in the process of weighing up
the pros and cons for this WG separation (the one
you propose in your draft) so I can't share an opinion
on that. However, this issue is secondary to me. 
IMHO the most important thing to do is to start by
discussing things like terminology and some of the 
more fundamental assumptions you propose. I prefer
to start by discussing that, rather than going
directly to the "recommendatios" section in your draft. 

So I'll later send a separate email with my comments
on those basic issues. It'll be much easier to discuss
recommendations once we start talking the same language.
At this stage, I fear I don't understand some of the terms
you use in the draft. 

comments on the way!

Hesham 

  > -----Original Message-----
  > From: James Kempf [mailto:[email-masked]]
  > Sent: Friday, February 28, 2003 6:39 PM
  > To: Hesham Soliman (EAB); 'Xiaoming Wang'; 
  > [email-masked]
  > Cc: [email-masked]; [email-masked]
  > Subject: Re: [mobile-ip] Draft on Mobile IP Architecture and Reorg
  > 
  > 
  > Hesham,
  > 
  > The draft is arguing that there is a separation between 
  > local and global routing
  > architecture for Mobile IP and that this separation should 
  > be reflected in the
  > organization of the WGs to do the protocol work. In normal 
  > IP routing, OSPF is
  > not used to advertise the default router to hosts, nor is 
  > it used on the
  > Internet backbone. There are separate working groups that 
  > do these protocols.
  > These protocols are separate and different and they are 
  > that way because there
  > is a natural architectural separation. The same applies to 
  > Mobile IP. Combining
  > these together in one working group has in practice been a 
  > disaster, IMHO.
  > Neither HMIP nor FMIP (and especially FMIPv4 even though it 
  > is complete!) has
  > made any progress in the last year and a half because the 
  > Mobile IP working
  > group has been concentrating on the base MIPv6 spec, which 
  > is fundamentally
  > about the global routing change (with a few minor tweaks to 
  > RFC 2461 thrown in).
  > 
  > About using HMIP for optimizing handover. I had a look at 
  > Appendix A of
  > draft-ietf-mobileip-hmipv6-07.txt. The mechanism proposed 
  > there requires address
  > preconfiguration, a particular deployment design, and a 
  > particular use of FMIP
  > HI/HAck signaling, as defined in the current
  > draft-ietf-mobileip-fast-mipv6-05.txt, but otherwise does 
  > not propose any direct
  > signaling between the MAP and the AR or MN that could be 
  > interepreted as mixing
  > together the local and global concerns regarding the 
  > handover routing change,
  > i.e. changes to RFC 2461. So I do not believe that this 
  > invalidates the
  > contention in draft-kempf-mobileip-arch-00.txt, about 
  > having a working group to
  > concentrate on the local link protocol. Such a protocol 
  > could include
  > preconfiguration. The actual protocol for HMIP could be 
  > done in the global group
  > or in a separate "regionalized mobility management" group, 
  > and the spec could
  > include something like Appendix A that describes how to use 
  > the RFC 2461++
  > protocol to do optimized handover (in the same way that
  > draft-ietf-mobileip-ipv6-20.txt recommends upping the 
  > router advertisement rate
  > from RFC 2461) for those that want to use HMIP for handover 
  > optimization, or the
  > use of HMIP for optimized handover could be in a separate 
  > draft. For myself, I
  > believe HMIP is too valuable for location privacy to 
  > squander on handover
  > optimization, but reasonable people can differ.
  > 
  > My larger concern is with FMIP, CARD in Seamoby, and the 
  > collection of
  > optimizations to RFC 2461 that have been kicking around the 
  > IPv6 working group.
  > There has been some sentiment expressed that there should 
  > be no "dependency"
  > between these protocols. In fact, they are intimately 
  > linked architecturally, as
  > Pekka and I outlined in our draft, and not designing them 
  > that way would result
  > in a mess, IMHO. In addition, some of the current features 
  > of FMIP mix global
  > MIP signaling into the local link protocol in a way that, 
  > again, I believe is
  > architecturally inapproprate. One of the beauties of the 
  > base MIPv6 design is
  > that it reflects the natural architectural separation in 
  > the protocol, and I
  > think it would be a mistake to do a remix.
  > 
  > Let's just agree to disagree on whether HMIP is good for 
  > handover optimization
  > or not and get on with trying to figure out how to achieve 
  > this reorg so that
  > the result is set up for success. Having just two working 
  > groups, one for IPv6
  > and one for IPv4, is, in my opinion, not likely to result 
  > in success.
  > 
  >             jak
  > 
  > PS: As to why I believe HMIP is more valuable for location 
  > privacy, the Japanese
  > regulatory authorities require location privacy for mobile 
  > phones, in the sense
  > that the owner of the phone must give permission for 
  > someone to obtain location
  > information about the phone. In IPv6, the location can be 
  > inferred from the
  > subnet prefix if the network is engineered with the usual 
  > mapping between
  > hierarchical routing topology and geography. For UMTS/GPRS 
  > systems, the GGSN
  > hides the location of the mobile terminal, and it will also 
  > do that for IPv6. It
  > can hand out IPv6 addresses at random without any mapping 
  > to geography because
  > hierarchical routing is not used below the GGSN. But for 
  > standard MIPv6 based
  > networks, HMIP is the only currently known way we have of 
  > being able to satisfy
  > this regulatory requirement. Therefore, wearing my Japanese 
  > service provider
  > hat, I would have to oppose any effort to tie HMIP more 
  > tightly to handover and
  > thereby preclude its use for location privacy, which is why 
  > I would like to see
  > Appendix A moved to a separate draft.
  > 
  > ----- Original Message -----
  > From: "Hesham Soliman (EAB)" <[email-masked]>
  > To: "'Xiaoming Wang'" <[email-masked]>; "James Kempf"
  > <[email-masked]>; <[email-masked]>
  > Cc: <[email-masked]>; 
  > <[email-masked]>
  > Sent: Thursday, February 27, 2003 9:09 PM
  > Subject: RE: [mobile-ip] Draft on Mobile IP Architecture and Reorg
  > 
  > 
  > >
  > >   > Local route repair is not a panacea for all possible 
  > situations. For
  > >   > example, two geographically adjacent access routers are
  > >   > separated with
  > >   > several hops away and with considerable delay. In this
  > >   > situation, local
  > >   > route will experience performance degrade, while regional
  > >   > mobility will
  > >   > achieve better performance.
  > >   >
  > >   > From above we can conclude that these two solutions both
  > >   > have their own
  > >   > locks that they are good at openning. For regional
  > >   > mobility, it happens well
  > >   > before the packet arrives the destination link and is
  > >   > suitable for the
  > >   > situation I stated above. For local route repair, it takes
  > >   > effect immdiately
  > >   > after the packet arrives the destination link and is
  > >   > suitable for the
  > >   > situation that previous and next access routers are not far
  > >   > in topology from
  > >   > each other.
  > >   >
  > >   > Therefore, I think there is need for regional mobility. The
  > >   > point is how to
  > >   > combine regional and local more efficiently, and with low
  > >   > cost and less
  > >   > complexity.
  > >
  > > => Amen... Please take a look at the appendix of HMIPv6
  > > and please let the WG know whether there are better ways
  > > of combining the two mechanisms. I'd love to get some
  > > feedback from anyone in the WG about this appendix. We got
  > > many comments on HMIPv6, but never on the combination of
  > > the two mechanisms.
  > > While you're at it, you might also be able to read:
  > > 
http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-02.txt
>
> It's pretty clear how it fits into this overall picture.
>
> Hesham
>