Re: [lisp] LISP Mobility Architecture

[Margaret Wasserman <[e-mail]>]

Hi Noel,

Thank you for your response.  It was very helpful, but I still have  
some questions/concerns...

On Jul 29, 2009, at 9:10 PM, Noel Chiappa wrote:
>
> 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. 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.

This is what I referring to in my earlier message when I said RLOC-to- 
EID transition.  I think that the term "boundary" is much clearer.   
Thank you.
>

>> 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.

In which direction do you think the boundary will move?

Am I right in my understanding that I can only have one LISP boundary  
between an end-node and the Internet core?  If so, will an end-site be  
unable to deploy LISP at their site boundary if their ISP has already  
deployed it at a higher level?  If that is the case, and the LISP  
boundary starts at the edges of sites, it would require a lot of  
coordination to move that boundary towards the Internet core later (as  
it would have to move upward for all sites at the same time, and the  
sites might lose some advantages that they have been enjoying).
>
>> 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.
>
> 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).
>
> 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.

This all makes sense to me, I think...

Your explanation basically says (as I interpret it) that LISP will  
allow us to give provider-independent identifiers (EIDs) to end sites,  
without adding routes to the core Internet routing tables.  There is  
an assertion/belief that end-sites will not care about what locators  
(RLOCs) are used to route their packets, as long as the identifier(s)  
(EIDs) that others (other end-nodes, users, customers) use to find  
them remain persistent, even if they move (topologically) within the  
Internet for whatever reason.  So, we believe that we will be able to  
freely change a LISP-enabled site's RLOCs to retain a high level of  
aggregation, even when a site changes ISPs or the structure of the ISP  
network changes.

If that assertion/belief is actually true, then I do understand (now  
that you have explained it to me -- thank you!) how LISP hopes to  
address the scaling issues with the global routing table, even if the  
LISP boundaries are at site boundaries.

I have some concerns about how well this will work, though...

We already (pre-LISP) have a situation where the DNS is often used as  
a mapping system to locate other sites and services.  The DNS name(s)  
of a site do not change when the site's address(es) change, so the DNS  
name could be considered a persistent identifier.  The problem is that  
certain properties of the DNS make it unreasonable to use DNS names in  
all of the places that we'd prefer to have a persistent identifier for  
a remote host.  Are we sure that EIDs (and the associated EID->RLOC  
mapping mechanism) will be acceptable for this purpose?  How are we  
planning to avoid the problems that have made the in the DNS  
unacceptable?

Margaret