Re: [lisp] LISP does not involve separate namespaces

[Dino Farinacci <dino at cisco.com>]

> Dino Farinacci allegedly wrote on 07/30/2009 15:31 GMT+02:00:
> > So, architecturally, the 2 address spaces are separate and can
> > implemented that way. It could be desirable to have an EID address  
> > out
> > of the 2002::/16 space or a RLOC address out of the 2610:00d0::/32
> > space. But it may not be needed with such a large address space.
> >
> > For IPv4, life is harder because of the vast install base, so the  
> > clear
> > separation is harder to appreciate. But you could have the same  
> > address
> > assigned from each namespace.
>
> Suppose a nameserver or some other piece of critical infrastructure  
> is in RLOC space, and an endpoint wants to talk to it.  What  
> happens?  How does the endpoint's site network, or xTR, tell whether  
> the destination address is an RLOC or an EID if the address spaces  
> overlap?

The ALT tells you if the destination is in EID space or RLOC space.  
But that is not sufficient. You have to consider other cases based on  
the source address of the packet.

If the source address of the site host is not from a list of  
configured EID-prefixes for the site, the ITR "natively forwards" the  
packet (which means it does not encapsulate it). So this would be RLOC- 
to-RLOC communication. If the source address of the site host is from  
a list of configured EID-prefixes for the site, the ITR will natively  
forward based on the first paragraph above. So this would be EID-to- 
RLOC communication.

When an ITR is not attached to the ALT, which is the default setting  
for a LISP site router (because we want it to be as low-opex as  
possible), it will have "negative cache entries, which are coarse  
prefixes that reside in the map-cache, with an action of "natively  
forward". The map-resolver sends these "negative Map-Replies" when it  
finds out that the destination of a Map-Request is not in the ALT.

The negative cache entries are very coarse so we can keep the smallest  
number as possible in the map-cache. I have included some "show ip  
lisp map-cache" output from an ITR on the LISP test network. Notice  
the bit patterns and prefix mask-lengths used based on a single EID- 
prefix block of 153.16.0.0/16 allocated to LISP sites.

Dino

----

LISP IP Mapping Cache for VRF "default", 9 entries

0.0.0.0/1, uptime: 1d07h, expires: 23:54:43, via map-reply
  Negative cache entry, action: forward-native

128.0.0.0/4, uptime: 1d06h, expires: 23:54:43, via map-reply
  Negative cache entry, action: forward-native

152.0.0.0/8, uptime: 20:26:25, expires: 03:33:34, via map-reply
  Negative cache entry, action: forward-native

153.16.10.0/24, uptime: 1d07h, expires: 23:58:49, via map-reply, auth
  Locator          Uptime    State     Priority/Weight  Data|Control  
in/out
  xxx.xxx.xxx.xxx  1d07h     up        1/50             0/0  |  909/910
  xxx.xxx.xxx.xxx  1d07h     up        1/50             0/0  |  910/910

153.16.19.0/24, uptime: 1d02h, expires: 23:58:49, via map-reply, auth
  Locator       Uptime    State     Priority/Weight  Data|Control in/ 
out
  xxx.xxx.xxx.x 1d02h     up        5/100            3/4  |  3065/3066

154.0.0.0/7, uptime: 06:58:14, expires: 17:01:45, via map-reply
  Negative cache entry, action: forward-native

160.0.0.0/3, uptime: 06:50:32, expires: 17:09:27, via map-reply
  Negative cache entry, action: forward-native

192.0.0.0/3, uptime: 06:49:30, expires: 17:10:29, via map-reply
  Negative cache entry, action: forward-native

----