In einer eMail vom 27.11.2009 22:09:22 Westeuropäische Normalzeit schreibt [email protected]:
> Dino, > Having read the Meyer-draft, I realize that "mobile node" does not > mean "mobile router" but rather "mobile user (handset)". I assumed > it means mobile router, which wrt LISP would mean mobile RLOC. Right, the LISP mobile node implements a simple version of an ITR and ETR and acts like an entire LISP site. So all the multi-homing features are available to the mobile-node. And when it roams, /32 host routes are not injected into the underlying routing system. > The draft mentions that it supports IP mobility without a home-agent. > Well , the truth is, a mn may proxy the home-agent to some limited > extent. The Map-Server is where the roaming LISP mobile-node registers to when its locators change. That *could* be viewed as a home-agent, but packets don't flow through the Map-Server like they would for a MIP home agent. The stretch from LISP MN to LISP-site CN is 1. Which means the shortest path between the two locators is taken. > This is not what I am talking about. My vision: If the DNS can > provide the geographical coordinates (RFC 1712 experimental) we > could route to the respective egress router, and in case this geo- > information is pretty vague (due to roaming within some scope of > geographical neighborhood) we can make a well-scoped search. You want to route based on topological closeness and not geographical. But more to the point you want to forward packets on a path that has less total queuing in each hop. That is reduce the number of hops. I want to do next hop forwarding based on knowing the internet's topology, however well reduced so that links between far remote nodes aren't contained - but certainly links from some node inside my own geo-patch (or inside my nearby geo-path cluster) to some node at the other half of the globe. If, by DNS, users are assigned their DFZ-routers' geographical coordinates, then that DFZ-router or any other one which however is closest to it (and which has been determined to show up e.g. in the world map ) would be taken as the destination node towards which a route can be computed and the respective first hop taken. There are many many more routes than just shortest routes which are loop-free (and even more than that, e.g. crankback routes whereby endless looping can be avoided certainly). I could even envision time-of-day routing !!! It could be a new dawn in routing technology i.e. the work base for generations of IETF-goers to come. Heiner > By other words: Abolishing the scalability problem is just a side > effect for better routing capabilities. > he fundamental difference is: All IP folks consider IP-addresses > routable although it is only mappable (as are MAC-addresses, too). > Wheras addresses, derived from the geographical coordinates have > always a well-known scope. Are you saying locator addresses are always geographical? And if so, if a node roams where its location changes geographically, does the address change? And is this address stored for end-point socket state? Dino > In einer eMail vom 27.11.2009 19:21:12 Westeuropäische Normalzeit > schreibt [email protected]: > > Thank you, Dino, for updating me wrt LISP&mobility and for sending > > the Meyer-draft. > > I do understand the organizational arguments with the LISP-charter. > > But wrt RRG, the mobility issue should have highest priority. > > Obviously, you can cater for mobility on top of whichever routing > > architecture. Proof: MIP4. > > But in search of a future routing architecture you can also come up > > with something that doesn't depend on a home-agent and which is > > also most appropriate for mobile nodes, i.e. some other than a > > mobility-jack-up solution. > > Well, yes, if you are going to build a scalable architecture, it has > to scale with the type of devices that Internet plans to deploy in the > coming decade. And we all know mobile phones will be ubiquitous. > Yes. That's why TARA is the best solution for it. You don't have to > disseminate where the geographical coordinates (x,y) are located:-) > > Regards, > Heiner > > > Dino > > > > > Heiner > > > > > > In einer eMail vom 26.11.2009 00:13:54 Westeuropäische Normalzeit > > schreibt [email protected]: > > Dave Meyer presented LISP-MN in the IETF Friday morning LISP WG > > meeting. The ID is enclosed. Dave can forward the slides he used to > > present. > > > > Dino > > > > > > > > > > > > > > On Nov 25, 2009, at 3:09 PM, [email protected] wrote: > > > > > Whenever I mentioned, how badly MIP is handled by all models of > the > > > well-positioned RRG-contributors, the response was silence. In the > > > LISP-mailinglist discussion this issue is officially > > deferred.Bottom- > > > line: Let's push LISP as it is and let's think about MIP later, > when > > > LISP is well anchored. > > > > > > It seams to me that inside RRG this issue isn't handled > > differently. > > > > > > Heiner > > > _______________________________________________ > > > rrg mailing list > > > [email protected] > > > http://www.irtf.org/mailman/listinfo/rrg > > > > >
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
