Introduction to LISP

I’ve been mentioning LISP several times during the last months. It seems to be the only viable solution to the global IP routing table explosion. All other proposals require modifying layers above IP and while that’s where the problem should have been solved, expecting those layers to change any time soon is like waiting for Godot.

If you’re interested in LISP, start with the introduction to LISP I wrote for Search Telecom, continue with the LISP tutorial from NANOG 45 and (for the grand finale) listen to three Google Talks from Dino (almost four hours).

Read my article @ SearchTelecom.com

Recent posts in the same categories

8 comments:

  1. Jan Zorz 09 September 2010 15:04
    You finally got the code? You need it for testing?
  2. Ivan Pepelnjak 09 September 2010 15:52
    The code is available. Testing - no time @ the moment. Working on an IPv6 strategy paper ;)
  3. cameron 10 September 2010 00:02
    LISP will die away like SHIM6, it is not a real solution. The real solution is turning on IPv6.
  4. Ivan Pepelnjak 10 September 2010 07:41
    Turning on IPv6 will not save you from the routing table explosion. LISP might.
  5. Petr Lapukhov 10 September 2010 10:01
    As long as we stick with hierarchical addressing and routing, the problems of multihoming and suboptimal routing will remain there :D Making EID address-space non-hierarchical might have solved the problem but non-hierarchical protocols have their own drawbacks.

    Since LISP-ALT uses IPv4 in EID space, it has to enforce strict aggregation to prevent the same explosion problems we have now with IPv4/IPv6 addressing. While this does not affect multihoming (due to RLOC/EID split), it definitely makes operations more difficult as advanced coordination is required to properly allocate address space and enforce aggregation.
  6. Ivan Pepelnjak 10 September 2010 11:30
    Don't worry, EID will explode. You will see host routes in EID ... but who cares; it's all in the control plane, where you can throw low-cost CPU cycles and low-cost dynamic RAM (on Moore's Law curve) at the problem.

    LISP solves just the problem of the core routers' TCAM explosion, nothing else.
  7. Petr Lapukhov 10 September 2010 12:39
    Not exactly sure how one can grow control plane state in a single device without increasing the forwarind state. Of course, forwarding table aggregation could be used to some extent, but that's a hack, not a solution. LIST-ALT pushes the forwarding state explosiong problem to the edge (just like the BGP-free core) but does eliminate the root cause - hierarchical addressing/routing. It could be so that in the future we'll face TCAM exhaustion in the EID space.

    However, to me, the forwarding state problem has been highly exagerrated :) After all, TCAM exhaustion was a good driver for buying new hardware and hence made sense for everyone (vendors making new equipment, SPs growring budgest and shifting costs to their customers, etc)
  8. Ivan Pepelnjak 10 September 2010 12:45
    Edge devices will use caching. Yeah, I know, every caching-based forwarding mechanism has failed.

    Facebook's or Google's edge devices will have "interesting" forwarding caches :-P

    BTW, you cannot defragment EID space. Each /24 (today) or /64 (tomorrow) that wants to be multihomed needs a dedicated entry with two RLOCs.
Add comment
Home
Sidebar