I am replying to Dino and Hannu. Damien's reply concerned how the ALT network would work - not the question of whether LISP implements the Locator / Identity Separation naming model.
Hi Dino, You wrote: >> An EID address is not an Identifier and an RLOC > > It is an identifier. It is used by the TCP and UDP socket layer. > Just because an EID is also a scoped locator inside of a site, does > not preclude it from being an identifier. > >> address is not a Locator. OK - I was trying to be brief. A better sentence would have been: An EID address is not only an Identifier and an RLOC address is not only a Locator. My next sentence states this clearly: >> Both kinds of address are like any IP address - they play the >> roles of both Identifier and Locator. though I should have written "any global unicast IP address". >> ITRs use a different >> algorithm for EID destination addresses. All >> other routers and all hosts make no distinction >> between EID and RLOC addresses. > > LISP does separate ID and locator because you can keep an EID fixed > with a system, maintaining session continuity, while changing the > locator associated with the EID. You can call an EID an "Identifier" but that doesn't make it so - EID addresses are Identifiers and Locators at the same time. (msg06082) An EID is just as much a Locator and an Identifier as any other kind of global unicast address. The only difference is that ITRs use a different algorithm in handling packets with EID addresses in the destination field than the do if the address is an RLOC. "RLOC" addresses are the "core" set of global unicast addresses - what is left after you "separate" the a new subset of scalable "edge" space, which in LISP is called EID space. You can call this "different Locator semantics" if you like, but that second algorithm is only found in ITRs. Hosts and all other router treat an EID address with exactly the same algorithms as they do an RLOC address. They have no awareness of the EID/RLOC distinction. An RLOC address used by a host or router is just like any other global unicast IP address - it is both an Identifier and a Locator of that host or router. When you specify an ETR address in mapping for an EID prefix, you are supplying a global unicast address (from the RLOC subset) to tell ITRs which ETR to tunnel the packet to. That is part of the new algorithm which ITRs use for implementing the EID destination address's Locator functionality. The address of the ETR is only a Locator for some EID-using host or network in terms of this second algorithm which does the ITR to ETR tunneling part of delivering the packet. Where the host or network is actually found, is a separate matter. Typically they are close to the ETR, but they are not exactly at the ETR. Hannu, you wrote: > Hello Dino > > Just a remark that in the mapping system discussions in the lisp list > the strong sentiment is that EIDs must be allocated and administered as > EID blocks to guarantee any efficiency and scalability. I think this is because all EID addresses must be covered by a prefix advertised by PTRs (Proxy Tunnel Routers). LISP has no name for such a prefix, but Dino recently referred to it as a "coarse" prefix. As long as, in general, each "coarse" prefix covers the address space of multiple separate EID prefixes, then routing scalability is achieved, because without LISP each such EID prefix would need to be advertised separately in the DFZ to achieve the same benefits to end-user networks (portability, multihoming and inbound TE). In Ivip, this "coarse" prefix is called a MAB - Mapped Address Block. > If the > identities are coming from blocks that are allocated to given > enterprises, then what happens when one of devices or a small remote > site joins to an other enterprise in an different EID block? This can be handled by LISP by making that host's EID address a separate EID prefix and mapping it to the ETR(s) of the network it is located within. Of course, that network needs to have its routing system handle that EID prefix, because the host uses that address for sending and receiving packets. So EID addresses are perfectly portable to any ISP where you can run an ETR, provided you can put them in EID prefixes. With IPv4 LISP, as far as I know, EID prefixes go to /32, so any amount of division is possible. It might be messy, for instance, to make a single IPv4 EID have a separate EID prefix if it was in the middle of an existing EID prefix. If it was the 09 address in a 16 IPv4 address /28 prefix, then there would need to be a bunch of separate EID prefixes to make up the full 16 addresses: 0 - 7 /29 EID prefix mapped to ETR N. 8 /32 EID prefix mapped to ETR N. 9 /32 EID prefix mapped to ETR Z. 10 - 11 /31 EID prefix mapped to ETR N. 12 - 15 /30 EID prefix mapped to ETR N. Ivip's micronets use arbitrary starting points and have integer lengths, so this could have been done in three micronets: 0 - 8 Micronet A mapped to ETR N. 8 Micronet B mapped to ETR Z. 9 - 15 Micronet C mapped to ETR N. > Renumbering > of EIDs maybe? How portable are the EIDs at the end of the day depends > on the mapping system structure and scalability. I would say that EIDs > are independent from locators for sure, but not from their allocation > scheme that ties them to topology. The allocation arrangement for EIDs has nothing to do with topology, since any EID address or prefix of addresses can be mapped to any ETR. - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
