RIPE-59 Lisbon, October 2009 Vince Fuller (for the rest of the LISP crew: Noel Chiappa, Dino Farinacci, Darrel Lewis, Dave Meyer, Andrew Partan, and John.

RIPE-59 Lisbon, October 2009

Vince Fuller(for the rest of the LISP crew: Noel Chiappa, Dino

Farinacci, Darrel Lewis, Dave Meyer, Andrew Partan, and John Zwiebel)

LISP updateLISP update

http://www.vaf.net/prezos/lisp-ripe59.ppt

LISP UpdateLISP Update RIPE-59 Lisbon, October 2009RIPE-59 Lisbon, October 2009 Slide Slide 22

AgendaAgenda• Problem Statement – good news & bad news• Brief review of LISP and LISP+ALT• LISP-MS map server/map resolver – an

easier way to access the mapping database• LISP-MN mobility• What’s happening in the IETF?• Implementation & Deployment Status• Spec References• Q & A


Review: Problem Review: Problem StatementStatement

• What provoked this?– Stimulated by problem statement effort at the

Amsterdam IAB Routing Workshop on October 2006• RFC 4984

– More info on problem statement:• http://www.vaf.net/~vaf/apricot-plenary.pdf

• First and foremost - scale the Internet– Growth trends in global routing system

state


Internet Routing StateInternet Routing State


Good news & bad newsGood news & bad news+ Recent analysis work by Geoff Huston

suggests that stability (update & withdrawal rate) may be improving

http://www.potaroo.net/presentations/2009-05-06-bgp2008.pdf

- Trend is still “up & to the right”- Multi-homing is still hard

+ LISP makes it easier and adds functionality

- Long-term trends are unclear

http://www.potaroo.net/presentations/2009-05-06-bgp2008.pdf


Review: What is LISP?Review: What is LISP?• Locator/ID Separation Protocol

– EIDs for hosts, topological RLOCs for “core”– Separate numbering allows routing to scale

• Ground rules for LISP– Network-based solution– No changes to hosts whatsoever– No new addressing changes to site devices– Minimal configuration file changes– Imperative to be incrementally deployable– Address family agnostic


Unicast Packet ForwardingUnicast Packet Forwarding

Provider A10.0.0.0/8

Provider B11.0.0.0/8

S

ITR

DITR

ETR

ETR

Provider Y13.0.0.0/8

Provider X12.0.0.0/8S1

S2

D1

D2

PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8

DNS entry:D.abc.com A 2.0.0.2

EID-prefix: 2.0.0.0/8

Locator-set:

12.0.0.2, priority: 1, weight: 50 (D1)

13.0.0.2, priority: 1, weight: 50 (D2)

Mapping

Entry

1.0.0.1 -> 2.0.0.2

1.0.0.1 -> 2.0.0.2

11.0.0.1 -> 12.0.0.2

Legend:

EIDs -> Green

Locators -> Red

1.0.0.1 -> 2.0.0.2

11.0.0.1 -> 12.0.0.2

1.0.0.1 -> 2.0.0.2

12.0.0.2

13.0.0.2

10.0.0.1

11.0.0.1

Policy controlledby destination site


Review: What is Review: What is LISP+ALT?LISP+ALT?

• Mechanism for an ITR to find the ETR for an EID• Advertise EID-prefixes in BGP on an alternate

topology of GRE tunnels• An ALT Device is:

– An xTR configured with GRE tunnels– A Map-Server (new)– A Map-Resolver (new)– A pure ALT-only router for aggregating other ALT peering

connections

• An ALT-only device can be off-the-shelf gear:– Router hardware, commodity Linux host, etc.– Just needs to run BGP and GRE


Using ALT to find an ETR

Legend:

EIDs -> Green

Locators -> Red

GRE Tunnel

Physical link

Map-Request

Map-Reply

ETR

ETR

ETR

ITR

EID-prefix

240.1.2.0/24

ITR

EID-prefix

240.1.1.0/24

ALT EID-prefix

240.2.1.0/24

240.0.0.1 -> 240.1.1.1

1.1.1

.1

2.2.2.2

3.3.3.3

EID-prefix

240.0.0.0/24

240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 1.1.1.1

ALT-rtr

ALT-rtr

ALT-rtr

ALT-rtr

ALT-rtr

ALT-rtr

12.0.0.1

11.0.0.1

?

11.0.0.1 -> 240.1.1.1

?<- 240.1.1.0/24

<- 240.1.2.0/24

< - 240.1.0.0/16

?

11.0.0.1 -> 240.1.1.1

?

1.1.1.1 -> 11.0.0.1

Original way: extend ALT to xTRs for policy control


New: LISP Map ServerNew: LISP Map Server• ETRs register site EID-prefixes with Map-

Servers– Securely with pair-wise trust model (no PKI needed)– Policy can be applied on Map-Servers before EID-

prefix accepted into mapping service– ETR is still authoritative for its database mappings

• Map-Servers advertise EID-prefixes in to the ALT on behalf of their client ETRs

• ITRs send encapsulated Map-Requests to Map-Resolvers instead of connecting to ALT

• Map-Server/Map-Resolver functionality may be in existing ALT router (most likely) or separate box

• draft-ietf-lisp-ms-03.txt

Using LISP-MS to attach xTRs

Legend:

EIDs -> Green

Locators -> Red

GRE Tunnel

Physical link

Map-Request

Map-Reply

ETR

ETR

ETR

ITR

EID-prefix

240.1.2.0/24

ITR

EID-prefix

240.1.1.0/24

ALT EID-prefix

240.2.1.0/24

240.0.0.1 -> 240.1.1.1

1.1.1

.1

2.2.2.2

3.3.3.3

EID-prefix

240.0.0.0/24

ALT-rtr (MS)

ALT-rtr

ALT-rtr (MR)

ALT-rtr

ALT-rtr

ALT-rtr

12.0.0.1

11.0.0.1

?1.1.1.1 -> 11.0.0.1

Easy way: xTR uses Map-Server/Map-Resolver

?

11.0.0.1 -> 240.1.1.1

11.0.0.1 -> 240.1.1.1

?

11.0.0.1 -> 1.0.0.1 11.0.0.1 -> 240.1.1.1

?

2.0.0.2 -> 1.1.1.1

1.0.0.1 2.0.0.2

240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 1.1.1.1

Encapsulated Data Packet


ETR

12.0.0.1

ITR

11.0.0.1

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link

S

D


Provider X12.0.0.0/8

PI EID-prefix 1.0.0.0/8

EID Topology


LISP-MS Detailed Example


ETR

12.0.0.1

ITR

11.0.0.1

S

D




Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

Map-Resolver, Map-Server and ALT Infrastructure

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link PI EID-prefix 2.0.0.0/8


ETR

12.0.0.1

ITR

11.0.0.1

S

D




Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

(1)12.0.0.1 -> 66.2.2.2

LISP Map-Register

(2)2.0.0.0/8

(3)2.0.0.0/8

[1] Map-Server Registration

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link PI EID-prefix 2.0.0.0/8

(4)2.0.0.0/8


ETR

12.0.0.1

ITR

11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

[2] Data request Triggers Map-Request

1.0.0.1 -> 2.0.0.1How do I get to 2.0.0.1?

11.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

11.0.0.1 -> 65.1.1.1LISP Packet

UDP 4342(1)

?

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link

(3) ?(2)

?

(4) ?

11.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

11.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

66.2.2.2 -> 12.0.0.1LISP Packet

UDP 4342(5) ?


ETR

12.0.0.1

ITR

11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

[3] Map-Request Evokes Map-Reply

1.0.0.1 -> 2.0.0.1How do I get to 2.0.0.1?

1.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

11.0.0.1 -> 65.1.1.1LISP Packet

UDP 4342(1)

?

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link

(3) ?(2)

?

(4) ?

11.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

11.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

66.2.2.2 -> 12.0.0.1LISP Packet

UDP 4342(5) ?

(6)12.0.0.1 -> 11.0.0.1

Map-Reply

UDP 4342


ETR

12.0.0.1

ITR

11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

1.0.0.1 -> 2.0.0.1How do I get to 2.0.0.1?

1.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

11.0.0.1 -> 65.1.1.1LISP Packet

UDP 4342(1)

?

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link

(3) ?(2)

?

(4) ?

11.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

11.0.0.1 -> 2.0.0.1Map-Request

UDP 4342

66.2.2.2 -> 12.0.0.1LISP Packet

UDP 4342(5) ?

(6)12.0.0.1 -> 11.0.0.1

Map-Reply

UDP 4342

[4] Map-Cache Populated, data packets can flow

PolicyControlled bydestination

site

EID-prefix: 2.0.0.0/8

Locator-set: 12.0.0.2, priority: 1, weight: 100 (D1)

Map-Cache Entry

LISP UpdateLISP Update RIPE-59 Lisbon, October 2009RIPE-59 Lisbon, October 2009 Slide Slide 1818Slide Slide 1818

New: LISP Mobile NodeNew: LISP Mobile Node• Simple host ITR/ETR implementation for mobile node

• MN registers with “home” Map-Server for assigned EID– Map-Server will “proxy” answer Map-Requssts

• MN uses Map-Resolver at its current location (roaming)

• MN encapsulates all traffic using LISP

• Use of Map-Server/Map-Resolver service interface– Enables scalable roaming with same LISP infrastructure used for

multi-homing and route scaling

• Map-Request flows to “home” Map-Server

• User data flows to RLOCs, so no “stretch” latency

• Map cache management slightly different for MN– Shorter TTLs, use of Solicit Map Requests, etc.

• See: draft-meyer-lisp-mn-00.txt (future WG document)


Roaming - Control PlaneRoaming - Control Plane

Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

Map-Server

Map-Resolver Map-Resolver

EID: 153.16.2.1 EID: 153.16.3.1

3.3.3.3 -> 65.1.1.1

LISP Map-Register

153.16.1.1 -> (3.3.3.3, 4.4.4.4)

153.16.1.0./24

EID: 153.16.1.1

Legend:

EIDs -> Green, RLOCs -> Red

3G network -> 3.0.0.0/8

4G network -> 4.0.0.0/8

BGP-over-GRE

Map-Register

BGP update

65.1.1.1

(1) No matter where MN3 roams, MN1 and MN2 can find it’s locator by using the database mapping system.

MN1 MN2

(2) Only the Map-Server will store 153.16.1.1/32 state with the latest set of RLOCs.

(3) Data always travels on shortest path to and from MN.

MN3


Map-Cache entry:

EID-prefix: 153.16.1.1/32

RLOC-set:

4.4.4.4, priority: 1, weight: 50


DNS entry:mn.abc.com A 153.16.1.1

Roaming - Data PlaneRoaming - Data Plane

Provider A1.0.0.0/8

Provider B2.0.0.0/8

S

ITR

ITR

4G Provider4.0.0.0/8

S1

S2

LISP EID-prefix 10.0.0.0/8

Legend: EIDs -> Green, Locators -> Red

1.0.0.1

2.0.0.1 EID: 153.16.1.1

3.3.3.3

4.4.4.4

WiFi Provider5.0.0.0/8

EID: 153.16.1.1

4.4.4.4

5.5.5.5

MN roams, stays multi-homed and TCPconnection does not reset

Map-Cache entry:

EID-prefix: 153.16.1.1/32

RLOC-set:



10.0.0.1 -> 153.16.1.1

1.0.0.1 -> 4.4.4.410.0.0.1 -> 153.16.1.1

3G Provider3.0.0.0/8

10.0.0.1 -> 153.16.1.1

1.0.0.1 -> 5.5.5.5


Review: LISP/IETF timelineReview: LISP/IETF timeline• Created over dinner at IAB RAWS (Oct ’06)• Lunch discussions at San Diego IETF (Nov

’06)• RRG in Prague (March ’07)• RRG and “lunch BOF” in Vancouver (Dec ’07)

– Tutorial and start of “LISP test center”

• RRG in Philadelphia (March ’08)• IETF (grow, rtgarea, idr) in Dublin (July ’08)

– EXPLISP BOF “process experiment”

• IETF (grow) in Minneapolis (Nov ’08)• IETF BOF in San Francisco (March ’09)


LISP in the IETF now LISP in the IETF now • Much deliberation on RRG list, etc.• LISP BOF in San Francisco (March ’09)• First WG meeting in Stockholm (July

’09)– Darrel Lewis & Sam Hartman co-chairs– Core LISP documents are now WG I-D’s

• Adoption of LISP-MN is still pending

• Discussion on WG list: [email protected]

mailto:[email protected]


Prototype Implementation Prototype Implementation

• Cisco NXOS, on NX7000 and Titanium– Underlying Linux code base

• Includes LISP, ALT, Interworking, and Map-Server/Map-Resolver functionality– “lig” diagnostic tool

• Software switching only• Supports LISP for both IPv4 and IPv6

– ITR, ETR, and PTR– LISP-NAT for IPv4 only


Other Coding EffortsOther Coding Efforts• IOS implementation under-way

– Loc/ID split functionality

• Considering IOS-XR implementation– TE-ITR/TE-ETR functionality

• OpenLISP implementation for FreeBSD; available and for a while and being updated– For testing the specs

• Considering native Linux implementation (and recently learned of preliminary work on one)

• Any other efforts?


LISP DeploymentLISP Deployment

• LISP Pilot Network Operational– Incrementally deployed during the last 2

years– 30+ sites across 7 countries

• US, UK, BE, JP, UY, AU, DE– Uses the NX-OS Titanium Platform

• IOS and OpenLISP platforms to be added– EID-Prefixes used

• 153.16.0.0/16 and 2610:00d0::/32• GRE tunnels out of 240.0.0.0/4, 32-bit ASNs

– RLOCs used• Current site attachment points to the Internet



LISP DeploymentLISP Deployment• LISP Interworking Deployed

– Have LISP 1-to-1 address translation working• http://www.translate.lisp4.net

– Proxy Tunnel Router (PTR) • IPv4 PTRs:

– Andrew, ISC, and UY• IPv6 PTRs:

– Dave (UofO), ISC, and UY• http://www.lisp6.net reachable through IPv6 PTR• http://www.ptr.lisp4.net reachable through IPv4 PTR


Open Policy for LISPOpen Policy for LISP• It’s been almost 3 years since the IAB Routing &

Addressing Workshop• This is not a Cisco only effort

– We have approached and recruited others– There are no patents (cisco has no IPR on this)– All documents are Internet Drafts

• We need and seek designers, implementors, testers, and researchers

• As always, please let us know if you are interested


Internet DraftsInternet Draftsdraft-ietf-lisp-05.txtdraft-ietf-lisp-multicast-02.txtdraft-ietf-lisp-alt-01.txtdraft-ietf-lisp-ms-03.txtdraft-ietf-lisp-interworking-00.txtdraft-meyer-lisp-eid-block-01.txtdraft-meyer-loc-id-implications-01.txtdraft-meyer-lisp-mobility-00.txtdraft-farinacci-lisp-lig-00.txt

draft-mathy-lisp-dht-00.txtdraft-iannone-openlisp-implementation-02.txtdraft-brim-lisp-analysis-00.txtdraft-meyer-lisp-cons-04.txtdraft-lear-lisp-nerd-04.txtdraft-curran-lisp-emacs-00.txt


ReferencesReferences

• Public mailing list: [email protected]• Core LISP team: [email protected]• More info at:

http://www.lisp4.nethttp://www.lisp6.net

RIPE-59 Lisbon, October 2009 Vince Fuller (for the rest of the LISP crew: Noel Chiappa, Dino Farinacci, Darrel Lewis, Dave Meyer, Andrew Partan, and John.

Documents

lisp updateripe

gre slide

lisp crew

hard lisp

unclear slide

alt eidprefix

destination site slide

internet routing state