Hi Scott,There are large organizations (you used to work for one of them, I believe ;-) where there are multiple Internet connections that have geographically widely dispersed contact points. Optimal routing implies that there will be different locator preferences for different hosts. Mobility within the organization itself implies that creating and maintaining meaningful identifier prefixes is going to prove challenging.There are two questions in here. - What do multiply-connected large organizations do? .... The good thing about ALT is that this fine granularity is not visible above the first 1-2 levels of the ALT hierarchy.I thought that ALT carried aggregated EID information. How does the correspondent host get EID-specific information? Did I misunderstand ALT?
Site-based EID-prefixes are injected into the ALT topology. ALT routers can further aggregate into the core. A source site sends a data packet or Map-Request to an specific EID that follows the route on the ALT topology to get to the ETR at the destination site which returns a Map-Reply with the a locator-set for the site-based EID- prefix.
- What is the effect of mobility within the organization? Let's be clear that in LISP an EID is not a persistent identifier of a *device*. It names a network attachment point or (from the other side) an interface. So "slow mobility" -- without a need for session continuity -- will involve assignment of a new EID. If there is a need for session continuity, then the problem is better solved at a higher layer. If it cannot be solved up there, then fast mobility mechanisms -- MIPv6 or whatever we settle on -- are appropriate. Solve it in per-connection signaling, not in the fundamental routing exchanges.If you go down this path, I'm having a hard time really reconciling the difference between an RLOC and an EID. It seems like if I move, I might change both, so that some location semantics has leaked into the EID definition.
If you move and you don't need session survivability you *can* change both. And to make that movement compatible with existing trends and deployed sites, you get a DHCP address (you as a host) that will be used as an EID. You (as a host) don't have locators per say, but the site you are at does (the IP addresses of the ETRs).
If you move and want session survivability, the EID must move with the host (and the host stack has to retain the address when the interface goes down, this is not common). This is the case where the RLOCs change for a single EID (versus the EID-prefix because the home site doesn't move, NEMO aside for a moment).
In other words, I think that we need host level granularity in the mapping function.It can be provided if needed, although I don't think it should be. InALT, single EID prefixes can be advertised to ALT routers which will then aggregate them, so the effect of long prefixes will damp out quickly.Which implies that EID-specific information will be lost, which in turn costs us functionality.
The more specific bits of an EID will be lost, but the mapping data is not lost because it is returned in the Map-Reply.
Excerpts from Tony Li on Thu, Jan 10, 2008 02:59:05AM -0800:? You missed my point: you pick all, simultaneously. You let your particular working set characteristics in your particular location select which particular approach you use at that particular location. All of the choices need to be integrated so that they result in one clean mechanism.We have already made that conclusion. You should have seen that at RRG.No, what I saw was a total mess of mechanisms, with no coherency.Man, that came out snarky. Apologies, it wasn't meant to be.
Thanks for the apology. ;-)
I like your idea, but there are complexity tradeoffs. You can get some of that dynamic adaptation with hybrid push/pull models, where the boundary between "push" and "pull" can move depending on load ... but we had better be sure we can debug problems with it before we allow that kind of dynamicity. Map&Encap and 8+8 are very different, but if we use Dino's idea of how to use IPv6 and map&encap maybe we could get dynamic boundaries between all of them. Should be studied further.Just in case I've confused anyone, I side with Einstein when it comes to complexity. ;-)
So using one mapping system would be better then.
A node *can* roam and preserve its original IP address, but we should not put that in the underlying routing. It can be done in connection signaling a la MIPv6.Fair, but unless we're willing to open the transports to actually add that to connection signaling, that's going to prove challenging. So far, all of the feedback on host changes (transport layer or otherwise) is all negative.
If the original IP address *stays* with the host, it continues to use it. So there are no hot changes.
Dino -- to unsubscribe send a message to rrg-request@psg.com 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