I am replying to Russ White's message 716 (Thoughts on the RRG/Routing Space Problem) regarding mobility.
Hi Russ, You wrote, in part, quoting Scott Brim: >> - Routing and addressing are more fundamental than mobility. >> Mobility can adapt to R&A but not vice versa. > > In other words, mobility is a secondary requirement for IP > transport. Either it is a small part of the traffic, and will not > grow, so there is no need to address it (?).... Or, it's not a > problem that needs to be addressed through routing, it should be > handled elsewhere. IE, IP == POTS. > > That "stuff" folks are running over our transport are fine, just > solve your own problems, and don't ask me to do it for you. IMHO, > this is shortsighted. I agree. An ITR-ETR scheme with mapping updates which take a few seconds to be implemented in all ITRs provides a whole new global system for highly optimised mobility - for both IPv4 and IPv6, with few new host requirements. The mobile host needs one or more care-of addresses and a tunnel from an ETR. It also needs a tunnel to an ITR, if it can't send packets out the way it likes from its care-of address. Ivip combines ETR, ITR and two-way tunneling into a "Translating Tunnel Router", as described in this and subsequent messages on the RAM list around 17 to 18 June: http://www1.ietf.org/mail-archive/web/ram/current/msg01547.html If something slow like LISP was built - slow global query system for pull (CONS and ALT), or slow push (NERD) - then people would soon be wanting to make it go much faster to support mobility. The high speed push Ivip intends to implement isn't just there for mobility support. It enables the end-user to implement their own multihoming service restoration system, with whatever reachability detection system they like, whatever logic, algorithms, manual controls etc. This is much more flexible and modular than forcing all end-users to rely on whatever logic is built into the ITR, by the RFC and the restricted nature of the mapping data. The fast push system also relieves the ITRs of the difficult job of deciding which of multiple ETRs to send packets too - with many such ITRs trying to figure out the same stuff on their own. Another major reason for the fast mapping updates is that it greatly simplifies the mapping data: just a micronet's starting address, its length and a single address for the ETR. This, in turn, enables the mapping system to work faster than if each item of mapping information contained a bunch of ETR addresses, priorities etc. (However, the non-Ivip ITR-ETR schemes which use such complex mapping data and demand so much of their ITRs have an advantage over Ivip in terms of load-sharing Traffic Engineering. Ivip can only split traffic over multiple ETRs by splitting a range of addresses into smaller micronets, and having one or more micronet go to one ETR and the others go to other ETRs. So Ivip can't split the load of traffic directed to one destination host.) >> - In the real world mobile users are rather >> provider-aggregated, and even if we use the currently conceived >> route optimization mechanisms, the need for new map lookups >> will be less than one would think. > > Today. Again, I believe it's wrong to base an architecture on > today's traffic patterns. Part of the job of the IETF isn't to > solve today's problems, it's to solve tomorrow's problems in a > way that doesn't impact today's services. Yes! IP mobility today is like cellphones in the late 1970s. We can only vaguely imagine what it might do, how useful it might be and how widely it will be adopted. The ITR-ETR scheme needs to be built anyway, to solve the routing scalability problem. Done right, it can be the basis for a new form of mobility with far surpasses the efficiency and usefulness of current approaches. Maybe we can get the cashed up mobile folk to pay for most of the costs of the ITR-ETR scheme. Hundreds of millions of people pay very high rates for cellphone services. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
