This follows from Noel's message, responding to Margaret, in the "Re: [lisp] LISP Mobility Architecture" thread: http://www.ietf.org/mail-archive/web/lisp/current/msg00744.html I haven't been following recent discussions and I don't have time to read about or critique the new LISP mobility ID. However folks interested in mobility might wish to compare it with a scheme which is applicable to LISP: TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem Robin Whittle, Steven Russert 2008-08-25 http://www.firstpr.com.au/ip/ivip/#mobile I will comment on these continued assertions about LISP involving two separate namespaces. Please see this page for links to all the previous discussion about the meaning of "namespace" and my posts to the list about this: http://www.firstpr.com.au/ip/ivip/namespace/ Noel Chiappa wrote: >> From: Margaret Wasserman <mrw at lilacglade.org> > >> It is my understanding that LISP provides a possible solution to the >> global route scaling problem because it creates two tiered routing >> domains: a global routing domain that uses RLOCS that are allocated in >> contiguous blocks that mirror the global network topology, and an edge >> routing domain that uses EIDs. I think this is an accurate description of LISP and the other core-edge separation schemes such as APT, Ivip and TRRP. There needs to be not too many prefixes which contain RLOCs, since each such prefix needs to be in the global BGP routing table - and a primary goal of any core-edge separation scheme is to reduce the number of such routes. > No, not really. Well, what you say is accurate, but it's only a _partial_ > picture of what's really going on. > > Like I said, the best way to think of LISP is that it's an incrementally > deployable system which splits the single IP address namespace into two > separate namespaces: one for location, and one for identity. These are not separate namespaces according to any definition I have been able to find. Noel, what is your definition of "namespace"? LISP involves two subsets of the global unicast address space. Some prefixes are in the global routing table and their addresses can be used for RLOC addresses. EID addresses are in other prefixes which are not within the first set, and so do not contribute to the burden on the BGP control plane by adding to the size of the global BGP routing table. A namespace is a context within which a number or name is interpreted. If there were two separate namespaces, then 12.34.56.78 would have one meaning on namespace 1 and another in namespace 2. Any situation which handles packets with addresses in two separate namespaces needs a way to figure out which namespace to use for each packet when interpreting the meaning of its address. However, what happens with LISP or any other core-edge separation scheme is that multiple prefixes of the global unicast space constituting the "RLOC-capable" subset of the address space are used for one purpose and the remainder of the global unicast space cannot be used for routing packets in the BGP core. That second subset can be used for EID addresses. LISP (in any form suitable for the foreseeable future, and as currently formally defined) does not allow the use of a single address for both purposes at once. This would be possible only if there were separate namespaces. In principle, LISP could work with separate namespaces for RLOCs and EIDs, but there is no way this can work in any time in the foreseeable future because it would require all BGP routers to also recognise these two namespaces. Then, the BGP routers would be able to see the packet destination address 12.34.56.78 as being either within the RLOC namespace, or the EID namespace. This would require modifications to all BGP routers and some new packet structure to carry information specifying the use of the RLOC or EID namespace. The whole idea of LISP, APT, Ivip and TRRP is to remain compatible with existing packet structures and BGP routers (though there are options in Ivip which do involve modified routers and packet structures as a way of avoiding encapsulation). I am sure that as long as LISP is to remain compatible with existing packet structures and BGP routers, that it does not involve separate namespaces for RLOC and EID addresses. > In keeping with > the 'incremental' part, there is a boundary between the (logical) part of the > network in which those two separate name(space)s exist, and the (logical) > part of the network in which there's only one; and the location of that > boundary can move over time. Noel, I would appreciate it if you described with a concrete examples how these two separate "namespaces" would work. I think this would illuminate some misunderstandings or at least point out the different meanings you and I ascribe to the term "namespace". > In the 'basic' LISP configuration, that boundary is at the very edge of a > site - to absolutely minimize the number of things that have to be changed > (e.g. hosts and routers inside the site don't have to be touched). There's an > xTR at the boundary (wherever that is) which encapsulates/decapsulates > packets; the encapsulated packet has both an EID and an RLOC (i.e. names from > the two separate namespaces). > > In the mobile node case, that boundary has moved right into the host: i.e. > _part_ of the host software understand that there are two separate > namespaces, and that the host has both an EID and an RLOC, and part (e.g. the > TCP) known only of the single 'IP address' namespace. > > > > I thought that the transition between the global routing domain (RLOCs) > > and the edge routing domain (EIDs) would happen at a fairly high level > > in the topology ... However, it seems that some of the design decisions > > being made in LISP ... are being made to enable the RLOC-to-EID > > transition to happen at the edge of much smaller networks (homes, small > > offices, etc.), perhaps even behind a local NAT box. > > Right. That's the 'location of the boundary moves over time' thing. > > > If LISP is deployed at the home gateway level, I am not sure how we > > gain much in the way of route scaling improvements, since we would have > > to support global domain (RLOC) routing all the way down to the > > per-home level, which is what we are doing today. I share Margaret's concern. This is not a problem with the TTR approach to mobility. > The thing is that we expect RLOCs to be assigned in such a way that they are > much more eggregatable (i.e. smaller routing tables). This is the goal of LISP etc. To achieve it, the addresses used by end-user networks need to be EID addresses. This includes any end-user network where a mobile device might have its care-of address. If Mobile LISP involves end-user networks having RLOC addresses, then I can't see how LISP could achieve its goals of making such networks portable between ISPs without renumbering and/or giving them robust multihoming via two or more upstream ISPs. You can't have some address 12.34.56.78 be both an EID and an RLOC. If an ITR treated this address as an EID, it would encapsulate any packet with 12.34.56.78 as its destination address and tunnel it to some RLOC address, based on looking up the mapping for 12.34.56.78. If any packet is encapsulated and tunneled to an address which an ITR recognises as being within the EID subset of addresses (which I think Noel calls the EID "namespace") then either that ITR or some other ITR will simply encapsulate the resulting packet as just described. This would continue for as often as the RLOC address returned by the mapping system was also within the subset of addresses known as the EID subset: that subset for which the mapping system will return an RLOC. It is absolutely clear that this has never been the intention with LISP. Every draft from 00 to the current 12: http://tools.ietf.org/html/draft-farinacci-lisp-12#page-8 includes this as part of the definition of EID: "EIDs MUST NOT be used as LISP RLOCs." If there were two separate namespaces for RLOC and EID space, then this statement would not be true. The same numeric address could be used as both an EID and an RLOC. > E.g. one problem has always been that people don't want to change their > hosts' IP addresses, because it's a pain in the XXX. So they keep their IP > addresses when they move, and that causes routing table bloat. > > To put it another way, the requirements of low routing overhead (aggregatable > addresses) and the requirement of ordinary users (have unchanging IP > addresses for their hosts) were diametrically opposed - and as long as we > only had a single namespace, there was no way to do both of those things at > the same time. > > Now, with separate EID and RLOC spaces, we can. RLOCs are assigned to be > maximally aggregatable, and EIDs stay constant no matter where the host(s) > move. E.g. when a small office moves to a different ISP, it can both keep its > old IP addresses, but without adding an entry to the core routing tables. > > So, to go back to your question: even if we have a neighbourhood full of LISP > MN's, the entire neighbourhood will still only generate a single routing > table entry - all the LISP MN's will have RLOCs allocated from a single > block, even if their EIDs are from all sorts of different blocks. > > > > So, what am I missing or misunderstanding? > > Did that clarify it? If not, please keep asking questions. Noel, how can a LISP MN act as its own ETR without an RLOC address of its own? From all I know about LISP, any such ETR function needs to have a unique IP address which is part of a prefix in the RLOC subset of the global unicast subset of the address space. If the MN is in an end-user network, and that end-user network is using EID addresses (as it must be be portable and scalably multihomable, as LISP provides), then its address can't be within an RLOC prefix. So how could the MN be its own ETR? By contrast, in the TTR approach to mobility, the MN is not its own ETR. It establishes a two-way tunnel to a Translating Tunnel Router, which with a single RLOC address is the ETR for many MNs in potentially many networks. The MN's care-of address can be behind NAT and it will still be able to make a two-way encrypted tunnel to the TTR. The TTR acts as its ETR and also handles outgoing packets, so the TTR is probably also an ITR. Multihoming and mobility is achieved by the MN tunneling to multiple TTRs, ideally a TTR which is "close" to the network it is tunneling from. - Robin
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.