LISP-DDT

LISP-DDT
Vince Fuller, Cisco
Glen Wiley. Verisign
NANOG-55 Vancouver, BC
1
Agenda
  Review of LISP: concepts and network elements
  The LISP mapping database today
  Description of LISP-DDT
  Development and deployment status
  Future direction
2
LISP Review – why do this?
  Initially, to try to find a way to scale the routing system
–  IAB Routing and Address Workshop, October 2006, RFC 4984
–  Separation of ID and location in IP addresses
–  LISP started during workshop, others have followed
  LISP-like indirection turns out to be useful for other things:
–  multi-homing with ingress traffic engineering
–  mobility
–  network virtualization
–  large-scale VPNs
–  ipv6 transition
3
LISP Review – why do this?
4
LISP Review – EIDs and RLOCs
 Endpoint IDs (EIDs) are used by hosts
–  assigned to “sites”, portable like “PI” space
–  not propagated by the global routing system
  Routing Locators (RLOCs) are used by the routing system
–  assigned to sites according to topology, like “PA” space
–  aggregated for use by the global routing system
  User data is LISP-encapsulated
–  RLOC source and destination in outer header
–  Source EID is “mapped” to RLOC by edge device
–  Mapping system consulted to find RLOC(s) for destination EID
5
LISP Review – network elements
  Ingress Tunnel Router (ITR) at LISP site
–  encapsulates user data in LISP datagram
  Egress Tunnel Router (ETR) at LISP site
–  decapsulates LISP datagram, delivers user data
  ETR/ITR functions typically co-located in one device (“xTR”)
  Proxy Ingress Tunnel Router (PITR), infrastructure
–  acts as ITR for non-LISP traffic (“legacy” Internet sources)
  Proxy Egress Tunnel Router (PETR), infrastructure
–  acts as ETR for non-LISP traffic (“hop over” non-LISP routers)
6
LISP Data Plane
Unicast Packet Forwarding
PI EID-prefix
2.0.0.0/24
PI EID-prefix
3.0.0.0/24
ITR
S1
10.0.0.1
Provider A
10.0.0.0/8
Provider X
12.0.0.0/8
6
11.0.0.1
S
2
LISP Site
S2
5
ITR
2.0.0.2 -> 3.0.0.3
1
Provider B
11.0.0.0/8
DNS entry:
D.abc.com A
3
12.0.0
.2
D1
7
Provider Y
13.0.0.0/8
13.0.0.
2.0.0.2 -> 3.0.0.3
2
8
D2
ETR
4
11.0.0.1 -> 12.0.0.2
3.0.0.3
ETR
11.0.0.1 -> 12.0.0.2
D
LISP Site
2.0.0.2 -> 3.0.0.3
2.0.0.2 -> 3.0.0.3
EID-prefix: 3.0.0.0/24
Legend:
EIDs -> Green
Locators -> Red
Physical link
Mapping
Entry
Locator-set:
12.0.0.2, priority: 1, weight: 50 (D1)
13.0.0.2, priority: 1, weight: 50 (D2)
This policy controlled
by destination site
7
LISP Review - Mapping Database
 EID-to-RLOC Mappings
–  Originated by LISP site ETRs
–  ITR sends Map-Request to ETR (via MR/MS) to obtain mapping
–  Mapping Database enables an ITR to find the ETR(s) for an EID
 Must Support Millions of Sites, Changes
–  Rapid response to connectivity changes
–  Less so for subscription-time database changes
  Prototyped LISP+ALT Using BGP+GRE+VRF
–  Was conceptually simple, operationally complex in practice
–  Lacked flexibility for adding EID types, instance IDs, etc.
8
LISP Review – Database Infrastructure
  Map Server (MS) – publishes EID-prefixes in database
–  ETR registers to one or more Map Servers
–  A Map Server publishes EID-prefixes so an ITR can find them
  Map Resolver (MR) – index for EID to ETR
–  accepts Map-Request from ITR, finds correct ETR(s)
  LISP+ALT – overlay network between MR and MS
–  tunnels and BGP sessions between MR, MS, and ALT routers
–  ALT routers are intermediate nodes that provide EID aggregation
–  Map-Request, not user data, is forwarded through the ALT to MS
–  ETR receives Map-Request from MS and sends Map-Reply to ITR
–  ALT is being replaced by DDT
9
LISP Control Plane – MR/MS with ALT
Map Request uses BGP/GRE overlay from MR to MS
ALT
PI EID-prefix
2.0.0.0/24
MR
S1
LISP->
Site
2.0.0.2
3.0.0.3
10.0.0.1
11.0.0.1
S2
ALT
ALT
Provider A
10.0.0.0/8
MS
Provider X
12.0.0.0/8
Provider Y
13.0.0.0/8
Provider B
11.0.0.0/8
ITR
DNS entry:
D.abc.com A
Legend:
EIDs -> Green
Locators -> Red
BGP-over-GRE
Physical link
PI EID-prefix
3.0.0.0/24
66.2.2.2
65.1.1.1
ITR
S
ALT
ETR
12.0.0
.2
13.0.0.
D1
2
ETR
How do I get
to 3.0.0.3?
11.0.0.1 -> 65.1.1.1
LISP ECM
(udp 4342)
3.0.0.3
[1]
11.0.0.1 -> 3.0.0.3
Map-Request
(udp 4342)
nonce
[2]
[3]
D
D2
LISP Site
[4]
11.0.0.1 -> 3.0.0.3
Map-Request
(udp 4342)
nonce
66.2.2.2 -> 12.0.0.2
LISP ECM
(udp 4342)
[5]
11.0.0.1 -> 3.0.0.3
Map-Request
(udp 4342)
nonce
10
What is LISP-DDT?
 LISP Delegated Database Tree
–  Hierarchy for Instance IDs and for EID Prefixes
–  Statically Configured
–  Delegations are signed (public-key) and verified when used
  Conceptually, similar to DNS (IN-ADDR hierarchy)
–  but different prefix encoding, messages, etc.
–  we did try using DNS protocol directly, but…
•  prefix encoding was painful/ugly
•  negative map replies were problematic
•  couldn’t do it right without protocol modifications
11
DDT Node
  Statically configured
  Authoritative prefix
–  IID and EID/length for which DDT node is responsible
–  root nodes have IID=any, EID=0/0
  Delegations
–  sub-prefixes delegated to “child” DDT nodes (or Map Servers)
  Accepts DDT Map-Request, returns Map-Referral message
–  contains pointer to node with more-specific information
•  NODE-REFERRAL for another DDT Node
•  MS-REFERRAL for a DDT Map Server
–  “negative” action codes also possible (more on those later)
12
DDT Map Server
  DDT Node may also be a DDT Map Server
–  accepts ETR registrations (just like any other Map Server)
–  forwards Map-Request to ETR
–  can return proxy Map-Reply (if configured to do so)
–  LISP-SEC authentication sent only following MS-REFERRAL
–  MS-ACK returned when EID fully resolved
–  “negative” action codes described later
13
DDT Map Resolver
  DDT Map Resolver finds RLOC for authoritative Map Server
–  Cache Map Request from ITR
–  Query the DDT hierarchy iteratively with DDT Map-Requests
–  Detect Loops/Delegation Errors
–  Follow referrals to find the right DDT Map-Server for an EID
  DDT Map Resolvers thus have state:
–  Referral Cache
–  Map-Request Queue
–  Key differences from “ordinary” Map Resolvers
14
Referrals & Their Actions
  ‘Positive’ referral is a pointer to a DDT node(s) with
information about a (usually) more-specific EID-Prefix
  Type 0, NODE-REFERRAL
  Type 1, MS-REFERRAL
  Type 2, MS-ACK
  DDT MR uses this information to contact the next DDT node/MS
  ‘Negative’ referrals are used to indicate other actions:
  Type 3, MS-NOT-REGISTERED
  Type 4, DELEGATION-HOLE
  Type 5, NOT-AUTHORITATIVE
  Referral includes public-key signature by delegator
15
DDT Node 1
Root
Configura)on and Setup Setup & Configuration
0.0.0.0/0
IID=0
1) MR configured with Root (DDT Node 1) RLOC
DDT Node 2
2) DDT-1, DDT2, DDT-3, DDT/MS-4 configured children
with child prefixes, and authoritative prefixes
Ex. DDT-2 Delegates child 10.1.0.0/16 to MS3
DDT-2 configured authoritative for 10/8 in IID0
10.0.0.0/8
IID=0
1 DDT Node 3
3) ETR is registering its EID to the Leaf MS
2 10.1.0.0/16
IID=0
MS1
DDT-Node 4
10.1.0.0/24
IID=0
3 MR
Static Delegation
Hierarchy
ETR-MS
Registration
ETR
10.1.0.0/24
Map Request
Map Referral
Map Reply
16
First Request Packet Flow Map Request, Referral, & Reply
DDT Node 1 Root
1) ITR sends MRQ to MR via ECM
0.0.0.0/0
2) MR sends Iterative-MRQ to its statically
configured Root DDT-Node via ECM-Likepacket
DDT Node 2
3 10.0.0.0/8
2 DDT Node 3
3) Root Sends a Map Referral to MR informing
the MR who is the next DDT-Node (2) to try
4) MR repeats steps 2 & 3 until it gets to leaf
MS1 (DDT-Node-4) which has the EID
registered (or an error indication)
5) MS1 (DDT-4) sends Map-Referral to MR
with action code MS-ACK
6) MS1 (DDT-4) receives, processes MR and
fwd to ETR
10.1.0.0/16
4 7) ETR sends Map-Reply to the ITR
DDT Node-4
MS1
10.1.0.0/24
6 5 MR
1 Static Delegation
Hierarchy
ETR-MS
Registration
Map Request
ETR
10.1.0.0/24
7 ITR
Map Referral
Map Reply
17
Steady State DDT-1
0.0.0.0/0
Once MR’s Referal-Cache is
Populated
DDT-2
1) 
2) 
10.0.0.0/8
DDT-3
3) 
10.1.0.0/16
4) 
MRQ in ECM arrives on MR
MR sends MRQ in ECM (possibly double
encaped if lisp-sec is used to secure
referal path) to Cached Map-Server MS1
(DDT-4)
MS1 decaps ECM and then sends MapRequest in new ECM to ETR
MS1 also sends a Map-Referal ACK back
to MR
ETR sends Map-Reply to ITR
DDT-4
MS1
10.1.0.0/24
2 MR
3 1 Static Delegation
Hierarchy
ETR-MS
Registration
Map Request
ETR
10.1.0.0/24
4 ITR
Map Referral
Map Reply
18
Implementation Status
  IOS and NXOS implementations complete
  OpenLISP implementation nearly complete
  Verisign implementation in progress
  Development and interoperability testing going on now
  Configuration is pretty simple
–  much easier to configure and operate than LISP+ALT!
  Does not include proposed DDT-SEC extensions
19
Organization and Operational Status
  Collaboration among Cisco, Verisign, Intouch NV
–  discussions with others, more welcome
  Common root: ddt-root.org
  Running on LISP pilot network
–  transition from LISP+ALT in March, 2012
–  ALT configurations removed in April, 2012
  Looking at various options for organizational structure
–  emphasis on transparency, scalability, efficiency, simplicity
20
DDT Beta (IID0) Network Deployment Iota- root Servers
Other DDT Roots
IID *
EID: *
sigma.ddt-root.org (Verisign)
mu.ddt-root.org
Cisco’s DDT Roots:
(Iota-Root)
IID: *
EID: *
arin-ddt.rloc.lisp4.net
ripe-ddt.rloc.lisp4.net
vxnet-ddt.rloc.lisp4.net
DDT Beta- Network TLDs
Beta Network DDT TLD
asp-isis
ARINRegion
MR/MS:
EID Aggregates:
153.16.0.0/19
2610:D0:1000::/36
2610:D0:FACE::/48
153.16.21.0/24 TO MN
153.16.22.0/24 TO MN
isc-mr-ms
asp-mr-ms
cisco-sjc-mr-ms1
eqx-ash-mr-ms
RIPE- Region
Mobile Node
Region
MR/MS’s
153.16.21/24
153.16.22/24
2610:d0:1219::/48
2610:d0:120e::/48
asp-isis
isc-isis
intouch-isis
MR/MS:
EID Aggregates:
153.16.32.0/19
2610:D0:2000::/36
l3-london-mr-ms
tdc-mr-ms
intouch-ams-mr-ms
intouch-ams-mr-ms
IID 0
v4-EID: 153.16.0.0/16
v6-EID: 2610:D0/32
uninett-ddt.rloc.lisp4.net
sj-ddt.rloc.lisp4.net
msn-ddt.rloc.lisp4.net
AP-Region
MR/MS:
EID Aggregates:
153.16.64.0/19
2610:D0:3000::/36
apnic-mr-ms
LACNICRegion
MR/MS:
EID Aggregates:
153.16.128.0/19
2610:D0:5000::/36
lacnic-mr-ms
DDT Node with
‘child referrals’
Static Delegation
Hierarchy 21
LISP Development at Verisign
  Verisign has operationalized a global public LISP
mapping database system
  Support OpenLISP development
  Multiple phases for Verisign LISP rollout
-  Pilot program to provide a secure and reliable EID to RLOC
Mapping Service (LISP-DDT currently)
-  Currently testing Customer Portal used for provisioning and
managing external customers
-  In-house developed LISP service using the same infrastructure
currently in place to support COM/NET DNS (Q4 2012)
22
LISP Footprint at Verisign
  LISP Pilot Network
-  Redundant Servers & Resolvers at each site
-  Redundant Transit from each site
-  Supports both IPv4 and IPv6
  Vendor Diverse Software Deployed
-  Dell R710s running NX-OS
-  Dell R710s running OpenLISP (June ’12)
-  Dell R710s running Verisign Mapping Servers/Resolvers (Q4 ‘12)
  Root Servers Deployed at multiple Datacenters
-  Dell R710s running NX-OS
-  Root IPs:
-  72.13.36.141
-  69.58.178.141
-  Efforts within our Labs, Engineering organizations in cooperation
with Cisco for some time now
23
LISP on Verisign Infrastructure
Process approximately
60+ billion DNS queries daily
70+ Global Points of Presence
4500+ computing devices
100% network uptime
more than a decade
Manages ~105 million+
domain names
The World Trusts Verisign to Operate
the Internet’s Critical Infrastructure
24
Specification & Standardization
  Individual Submission in IETF LISP WG
–  draft-fuller-lisp-ddt-01.txt
  Work In Progress, -02 draft will be out soon
–  better integration of action code descriptions
–  additional work needed on security extensions
–  finite state machine for pending request processing
  Consistent With WG Charter
–  planned adoption as WG draft
–  expected replacement for LISP+ALT
25
Future Work
  LISP Mapping Provider “eco-system”(?)
  Internet-Scale Deployment(?)
26
LISP Resources
  www.lisp4.net
–  background information, pointers to other presentations
–  pilot network topology, traffic, etc.
–  LISP Network Operators Group (LNOG)
  lisp.cisco.com
–  Cisco implementation info, image downloads, etc.
  [email protected] - IETF LISP working group
–  https://datatracker.ietf.org/wg/lisp
–  “core” documents scheduled for RFC publication “RSN”
  LISP-DDT route operation - http://ddt-root.org
27
Questions and Comments?
Contacts:
[email protected]
[email protected]
[email protected]
(especially if you’re interested in participating )
28