On Tue, Feb 2, 2010 at 5:00 PM, Noel Chiappa <j...@mercury.lcs.mit.edu> wrote: > > From: Patrick Frejborg <pfrejb...@gmail.com> > > >> Ah, no - LEID's are globally visible, and globally unique. > > > Do they really need to be globally visible and globally unique in the > > future? > > Yes - they need to be globally visible because they are the names that > endpoints use to identify each other, and you may want to talk to another > endpoint anywhere (hence the need for global scope). > If you take the core-edge philosophy and apply that on the address space - creating a hierarchical address space the endpoints can still be identified though they use the same edge space. With LISP terms, if the RLOC is telling the attachment point to Internet and the EID is telling the attachment point at the local network you have a two level address space. And the local network address space can be reused if the global address space is unique - similar as in PSTN but without geographical boundaries, it should follow as much as possible the AS and RIR structures that is in place (some trade offs are needed).
> > > Do we need network aliveness detection or is this functionality > > something that an endpoint could take care of? > > An endpoint is interested if the remote endpoint is alive or not > > When you say "network aliveness detection" I gather you mean 'detection of > endpoint liveness by the network'? If so, yes, I agree, we should probably > not have the 'network' (by which I assume you mean routers) doing liveness > detection. Right > > > if there is a problem the endpoint could try another path to the remote > > endpoint > > The problem is that in the current state of the architecture (in particular, > the routing architecture), the host can't really do this. Yes, in those cases > where the destination has multiple locators (because of either site or host > multi-homing), use of another locator _may_ bypass the problem. > > However, this is a degenerate case: not all endpoints will have multiple > locators; the problem may be close to the source, so that different > destination locators all still cross the same failure point, etc, etc. Thus, > in many cases where there is a usable alternative path, that path with not be > discoverable through use of an alternative locator for the destination. > > So the real solution to that particular issue is a better routing > architecture. > Agree, but instead of telling the world my edge prefix I tell to the routing architecture my attachment points (in LISP, RLOC values - in hIPv4 Area LOCator, ALOC). Then the routing architecture will have a lot less prefixes to carry, the remote endpoints knows my attachment points and in case of failure they can try different attachment points but my endpoint value (In LISP EID, in hIPV4 Endpoint LOCator, ELOC) remains unchanged. Less work for the routing architecture, little bit more work for the endpoints but since MP-TCP is arriving anyway why not use that resource to improve the routing architecture? So my server could have the following address 192.168.1.1:10.10.10.10 and 172.16.1.1:10.10.10.10, the first is the ALOC value and the latter is the ELOC value > > > IPv4 will be around for a very long time - especially in the old > > economies > > My point was stronger than that, actually - I was arguing that IPv4 addresses > will be _central_ for a long time to come. > You too, I hadn't the courage to state that :-) > > But if you ease up the rule of globally uniqueness a little bit then > > you could start to reuse the edge prefixes and perhaps reduce the > > amount of NAT > > Huh? NAT is _precisely_ 'making edge prefixes not globally unique'! This is > done so that a single prefix can be reused - the exact goal you list! > > For example, the prefix 192.168.0.0 is already reused over and over again. > > Are you talking about re-using the addresses on the other side of that NAT? > That's just double-NAT. NAT _is_ re-use of prefixes. > No, it is not really NAT though that is the first thought that many have - you carry both source&destination ALOC/ELOC values with the header all the time - but the API will see just legacy IPv4 addresses. So no address hiding, the edge addresses (EID/ELOC) will never show up in the DFZ and the ELOC can be PA and PI-addresses. PI-address here=own by the enterprise and will not show up in the core-DFZ but it will show up in the edge-DFZ. -- patte _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
