LISP Part 2 - Mapping Database Infrastructure and Interworking

Uploaded by GoogleTechTalks on 25.03.2010

Well, thank you all for coming to the LISP Part Two Talk. Once again I will now introduce
the man who needs no introduction, Dino. >> FARINACCI: Welcome all. So, let's see,
who wasn't here last Wednesday? Everybody, okay. So I'll just go through--there's a few
slide summary of what we've talked about and then we'll go into part two, and then give
you a preview for part three which is next Wednesday. Summary; we're going to start talking
about the design goals for a mapping database, a couple of mapping database algorithms, and
service interface that we have to the mapping database, and then talk about how LISP sites
talked to non-LISP sites, we call that interworking, not necessarily transition, but we call it
interworking, and then some security and network tools that are available and issues, and a
preview for next week. So the first thing we've talked about last week was we want to
control the core routing table growth, and we can do that with a level of interaction
by not injecting EID-prefixes into the underlying routing system. And by doing that, we could
also provide low apex multi-homing and have the site control which way packets come in
on each of their links. That was the fundamental multi-homing used case that LISP can provide.
We're going to talk about some used cases next week; datacenter used cases, mobility
used cases, but the one that was able to give us the best used case was scaling the routing
tables and being able to do this multi-homing. These slides are just extracts from last week,
you're not suppose to read them, it's just those are the general slides that are referring
to those topics. What we did or trying to do is separate address space into Endpoint
IDs and Routing Locators, we call them EIDs and locators for short. And by creating a
level of interaction, it allows us to avoid renumbering sites and allows the top topology
to roam. So you can roam topology because the site addressing could stay the same, and
you just change the locators that access those EID-prefixes. LISP is the protocol in the
architecture to do that. LISP was a network based protocol to achieve the separation in
an incrementally deployable manner. You don't have to change site routers or core routers.
We believe the sweet spot for LISP, but it's not limited to is the CPE boxes. LISP uses
packet encapsulation versus translation like a net could do. A net is another example of
an EID locator split. It just separates out a private address and a global address that's
used, but LISP uses all global addresses, and packet encapsulations which used to be
able to separate addresses and we map from an EID to a locator to be able to build the
outer header. We described a Unicast and Multicast forwarding example, when there was a map-cache
hit. So when there was a map-cache hit, we used it, we encapsulate packets; we decapsulate
on the other end. What we're going to show you today is that when we get a map-cache
miss, how we go get the map-cache entry, and that's the mapping database system that we'll
spend probably half the talk on. We showed how site policy and core policy will be achieved
independently. How the site can decide which way packets come in if it once active/active
multi-homing active backup or once it'd be per source or per destination. These policies
are--can be achieved with pretty rudimentary tools. And then we talked about three mechanisms
to deal with; MTU handling, we don't believe it's a problem. You could add protocol machinery
to solve it, and we talked about locator liveness algorithms. So, the locators are always assumed
to be up when you receive them in a Map-Reply, in a map-cache entry, and then you find out
when they go down or when they come up using the locator liveness algorithms that we've
talked about. And then we just we talked about a little history of LISP and the open policy
for it. We described that LISP started--its work started in the RRG, the Routing Research
Group, of the IRTF and now it's an IETF working group. And we indicated that it's completely
open with an emphasis of this is not a Cisco only solution, this is an industry solution
and Cisco has no IPR. So let's move on to the talk. Anybody want to ask any questions
or anything before I start? Okay, so the Mapping Database System. So what we talked about last
week was machinery that's kind of have been known, have been built before. It's not really,
you know, inventive or state of the art. We're just using existing mechanisms and just trying
to define it in a very specific way and implement and learn about it. This part, the mapping
database is kind of the researchee or the new stuff, the new secret sauce, so to speak.
And because we have to be able--when an ITR gets a packet and when an encapsulator gets
a packet, it ceased, it looks at destination address and it cut--it thinks it's an EID.
So that's the key to the database look up, and so it needs to get a locator set back
so it knows where to encapsulate packets. And we want to require the site, the destination
site to be authoritative and have security--secure control over how it replies. And the kicker
is--we think we needed to scale to 10 to the 10th entries, that's ten billion. It's pretty
large database, arguably it's an MP complete problem because if you can scale it to 100
million or a billion arguably, you know, 10 to the 10th is using the same set of algorithm.
So we'll see, and you guys could be the judge if you think we can scale it to this size.
The database needs to be dynamic, meaning that we need the locators to change not real
quickly, but at subscription times. If you reconnect to an ISP, if you maybe roam from
one subnet to another, we need to update it. So, it's very much like DNS with dynamic updates
maybe at the same granularity of time. We'll see as time goes on if we're going have to
be much faster than that. So that's built in day one. And obviously the algorithm has
to be distributed so we can load split Map-Request that go to different places. We need to use
the entire network, all the boxes band CPUs that are available, and we don't want the
database to be in one specific place or a set of places or it could be DOS attacked.
So by being distributed, we've seen this with Bittorrent applications that if it's distributed,
it's really hard to knock the service down because it's everywhere and you can't find
it all the time. And so that's a good benefit to stay ahead of the cat and dog game when
it comes to security. So scaling Internet databases; this is really fun. We need this
EID to locator mapping service. And really the Internet today really only has two large
databases; one is called BGP, and one's called DNS; and they're pretty fundamentally different
and I'd argue that they're different extremes where BGP pushes all the information everywhere.
It's assumed that the information you need to route a packet is being told from anywhere
to everywhere. So when you get a routing table hit, you can forward the packet on the next
hop, but if you get a routing table missed, you should drop it because it's an unreachable
or an unallocated address. Okay, so it assumes the model default and assumes that everything's
pushed hop by hop everywhere. DNS is completely different because it has a scale at a completely
different level where we will pull data only when we need it from servers, and it scales
to probably two or three orders magnitude more than what the BGP table is intended to
scale. Now what makes BGP scale is because the key or the information that's being passed
around in this database is in the power of two, it has a power of two key and it's called
the IP address or IPv6 address, and because you can shorten the prefix, you can aggregate.
So, you can take eight entries and advertise--if it's in the same power to block, you can advertise
it into one prefix and lower the bits--lower the mass link by three bits. And because you're
allowed to do that as the information goes farther and farther away the advertisement
information goes farther and farther away, you can advertise more course information
and be able to scale the routers that are farther away from the destination whereas
the packet then moves towards the destination, each of the routers have more and more specific
information to find the exact point where the destination is. So that's how we're able
to scale to a certain extent if you can keep things in nice power of two boundaries, sometimes
that's challenging when you have back towards and special policy cases and stuff. Now, DNS
names are not--they don't have power two keys. They're just free formed ASCII characters
that are basically flat. So if you want to look at and, basically, there
are two different entries that have to go into this database. So the only way to scale
it is that you need to use a cache, and you only store what you're using on demand and
that's how DNS is able to scale. So, you basically pull or push and you need to choose your poison
because when you want to scale 10 or the 10th, it's not clear which is better, okay? So we
need to tradeoff state times rate. We know that the state's going to be 10 to the 10th
if we can keep the rate down, that factorial there will remain small. If they both have
to be large numbers, we may have an MP complete problem. So we're trying to say that the state
will be large and the route turn will be low and that will maybe help us solve this problem
and we'll show how we're going to go about it. Did I mention we have to scale to order
10 to the 10th? It's really important. Okay, so Mapping Database Algorithms. We have a
few of them, and we documented most of them. I have to tell you that they don't work and
they don't scale enough. So, when a new person comes along and says, why do we try this?
We say odds in this class, go look at this. And then we have one in particular that has
most promise. There are others that tradeoff things differently and there's interesting
new data structures like DHTs that could be used for this as well. But we'll go through
each of this pretty briefly because we want to talk about the one that we're using now.
So we have to tradeoff push versus pull and see what the benefit cost ratio is. So we
have this one called NERD, and basically it's a full push, let's make it look like BGP,
let's push all the data mappings everywhere. Let's push it from a few authoritative sources
and some sort of trust chain and they could be signers. So you know that the information
is legitimate in coming from the right place. And then when you do map-cache lookups in
the encapsulator, you will never miss. It's either there, and when it's there, you encapsulate
when it's not you should drop the packet on the floor. Okay, that makes the encapsulator
pretty easy. You don't have to have any control plane machinery at that point. But that kind
of violates the 10% routing table rule. That routing table rule is from Jeff Houston's
data saying that a typical router today is 350,000 routes and it's in a core routing
table. But when you when you look at a 24-day packet trace of it, it only touches 10% of
those destinations, so only 35,000 routes are being used out of 350,000. Is that a good
use of memory? You might want to question that. So maybe on demand caches depending
on where you are in the network, is a better way to do routing. And maybe with LISP now,
we should change the paradigm and not use push hop by hop protocols but use a database,
and when you need to go somewhere, you go request and get the information you need,
cache it and then you use it. So that's kind of a paradigm shift that we're kind of going
towards now with LISP because it's a cache-based system. So, do you really want to push all
this stuff everywhere? Well, my Linksys router probably doesn't need a map-cache entry. My
Linksys router at my house probably doesn't need a map-cache entry for Taiwan because
I don't go there very often. Okay. I may go to China more often, so how do I decide to
do that? Do I tailor it? What do you do? It's probably less is always better and so, it's
probably a good idea not to have to push this around. We did some calculations on this and
show that only with a few gigabytes of memory you can probably store everything. And if
you compress it, it doesn't take long to download it. The question is about dynamic updates.
Dynamic updates would always be trickling in, you have to manage that. This is probably
a non-starter, so we kind of put it in an obsolete sort of state. We have something
called EMACs where we say, "Let's try pull, but let's do intelligent pull." Maybe we can
take the EID and hash it to a multicast group. And then all of the ETRs, the decapsulators
join that multicast group, and then I can send a Map-Request when I need that information
to the group. Of course, a bunch of people will get it which will knock that destination
EID, but the one who is, will be the one who can send the Map-Reply back giving me the
information I need, okay? So the first thing, maybe for non-starter is, "Oh, what if I'm
at my house and my EID range is the same as Google?" I'm going to be giving a lot of Map-Request
in because I'm joining the same multicast group does as Google, so probably not a good
idea. So we put that on the obsolete shelf. CONS had a lot of promise. We said let's try
to do a hybrid push pull, and we will push EID-prefixes because pushing them with aggregate
ability of power of two addresses would be something we can do. And we could do that
in a multilevel thing. You can't build a pure hierarchical thing because every ISP wants
to be at the top. We live in a peer-to-peer mesh ISP type model, so what we want to do
is build tier one's tier, two's, where all the big guys can be up there together doing
link-state and the next level, the next tier two guys can be doing link-state. And so this
was a way to push the EID-prefixes on this thing and then have the Map-Request go up
to hierarchy, come back, and have the Map-Replies go back and fourth. This was a completely
brand new protocol and we looked at it and we said, "Hey, we're using a lot of technology
from the past link-state path vector these sorts of things." But one thing that's bad
is that the Map-Replies have to follow this hierarchy and they may incur latency versus,
you know, just going straight. You know, I have to go ask somebody where they live but
they say, "Before you ask me where you live, come over to my house and I'll tell you."
Okay. And so it's that catch 22 situation that we're in. So, we came up with something
called ALT which was similar to CONS. Pushing EID-prefixes is probably not a bad idea, and
if we can do it on alternate topology, we could probably make the scale really well.
Today, when you connect into the Internet, your address that you connect into is based
on the topology. So you're addressing depends on topology. If we can build a logical topology
that depends on an allocation policy that the IRRs are going to give out, we can make
this network map hierarchally in a power of two chunks and really make the core store
very few routes. So what we want to do is let's push these EID-prefixes around using
BGP, because we just need a routing protocol. Let's use DGP as a distance vector protocol
and let's have the BGP connections between this ALT routers peer over GRE tunnels. Why
GRE tunnels? Because we want this to be a logical topology, we don't want any physical
association of this box with the underlying topology. We just want some peering model
between VeriSign and Go Daddy, or RIPE and AARON. And it doesn't matter where they are.
And by the way, those BGP peering connections are going to stay up because there's a whole
Internet underneath you that's keeping the tunnels up. So the tunnels won't go down,
the peerings will be stable, and we'll have a very strong aggregation on this topology,
you'll see in a minute. No changes the BGP whatsoever. These ALT routers can be off the
shelf of Linux boxes. They can be Juniper routers, it doesn't matter. You're just taking
a packet called the Map-Request and you're routing it on this logical topology. So we
think ALT has the most promise and we've been looking at it quite a bit, wherein I think
our third or fourth rev of the Internet draft and we haven't deployed. We'll talk about
the deploy--the deployed network next week. But we think it has a lot of promise and it
just dropped in so simple. It was one of the easiest technology introductions that we could
have ever done and we'll explain in more detail how this ALT works, okay. So basically, we're
building. Go ahead, Steven. >> STEVEN: I have a question.
>> FARINACCI: Yes. >> STEVEN: Since this--since your, you're
using [INDISTINCT], the, you know, the DNS packet and then it says, why don't you just
publish this [INDISTINCT] hierarchy or the [INDISTINCT] hierarchy and then we get all
of the [INDISTINCT] authority and, you know, all the mechanisms of DNS for free and [INDISTINCT].
>> FARINACCI: Yes, that's all right. So the question was is, we already have a mapping
database system, it's called DNS, why can't we publish these prefixes in ".net" or ".arpa"
and we can--we have DNS updates, we have DNSSEC and all of these sorts things. So we definitely
started there at day one saying, "Why don't we use DNS?" And there's been many variations
of that up to now. So first, the first got--immediate reaction was, you don't want to wreck and
you depend on routing, and you don't want routing to depend on directory so that's an
interesting thing. If you needed to get to the directory, you'd have to use locator space,
and you couldn't use LISP to get to rehab to catch 22 that was the first thing. Then
the other thing is, is well, maybe we just used DNS the protocol build a completely different
set of hierarchy, and maybe we send our packets to something other than port 53 or whatever.
And that's certainly can be used it as well. And, you know, there is--the problem that
we thought could occur and there's a proposal now called LISP tree that the guys in Europe
are doing, where they want to look at this hierarchy like we built with ALT, but they
want to look at to see if this EID-prefixes could be cached, not the mappings, but the
EID-prefixes can be cached and that you can lower latency. We're just not finding on the
network that latency is a big problem; it really isn't that much of a problem. So we'd
rather keep the center transport of the Map-Request pristine because if we have to pull out the
middle in put in a DHT or the DNS idea, that you have Steven, we certainly can do that.
But we don't want to change the edges, the XTRs, the encapsulators and decapsulators.
We want them to interface to this service interface which we'll talk about in a minute
which are made up of Map-Resolvers and Map-Servers. So we have thought about it, but there's,
you know, I mean, of course, the IETF is going to say no, no, no, and basically you could
actually use DNS as the PKI as well and you can have--you can put, you know, public and
private shared keys in there or keys in there and have a hierarchy of trust, and that would
work well also. But, the DNS spec say, you're not supposed to use that as a general PKI,
DNSSEC is supposed to use the secure DNS, okay, so.
>> Also, that's the domain this [INDISTINCT]. >> FARINACCI: Right. Right. So this is kind
of the model that we have so far, and we want to make it modular so we can pull out that
red thing. Now what's important to note is that the caching and the database Map-Replies
happen at the edges and that's where it's authoritative. And the access to how you get
Map-Request from this site to this site is serviced by these Map-Resolvers and Map-Servers
which we'll talk about it in detail. And then these guys are just transporting those packets.
The ALT is basically a control plane infrastructure just to move Map-Request. The single packet
I've called the Map-Request which has an IP header on it. So a Juniper router can take
a Map-Request which has an IP packet of a GRE tunnel, look it up in a BGP RIB, send
it out another GRE tunnel to get it on its path towards the destination site whose authoritative
for responding, that's the idea. Questions? So let's talk about the Mapping Service Interface.
Well, this was the example we have the last time where we have S was talking to D and
it wanted to inject a packet. Remember throughout this presentation, green means EIDs and red
means locator addresses. It will be consistent throughout the presentation. So we see that's--the
sources in out of the provider-independent EID-prefix that's been allocated to the site,
the 1/8, and it's going to send a packet to, which is this address. Okay. So what
we said the last time was when S2 got the packet and it had a map-cache entry we would
just encapsulate to the locator D1 or D2. What we're going to show you now is that the
map-cache lookup nest and so what does it have to do? So what it does is it sends--it
builds this control packet called a Map-Request so the destination address in the
IP header says--it's, that's what I'm looking for. That's the database lookup
key. And the source is actually the encapsulator or to the encapsulator that his RLOC, his
IP address is going to be in the source, so he has to send that somewhere. Let's just
say for now, it gets to one of these two boxes that own 2/8, and then they're just going
to send the Map-Reply back to the requestor, which is and it's coming from, say,
D2, that's the Map-Reply, that's the basic service interface. It looks very much like
an ARP request and an ARP reply on a single subnet. That's kind of the idea. We'll talk
about how it all happens in the center in a couple of slides. What happen is when the
Map-Reply comes back, it has an EID-prefix. It doesn't have They have EID-prefix
for the entire site. So we have aggregate-ability in the map-cache engine. When we said, 10
to the 10th, we meant 10 to the 10th sites not 10 to the 10th systems. So it's a lot
of individual IP addressable systems. So this 2/8 is the entire site here and we're saying
that the two locators that you need to encapsulate to, to get to anybody in 2/8 is and We showed that last time. Once that Map-Request/Map-Reply exchange happens, you
have the information you can encapsulate too. >> Well, that's great. You know, in Map-Reply,
the issue of including information about the subnet must be [INDISTINCT]?
>> FARINACCI: It's pre--the question was is that subnet mask information in there? It's
2/8, it's not subnet information. It's the entire power of two prefix that's used by
that site. So out of the 2/8, there's a bunch of subnets here that have more specifics;
0/16 and 0/24s that come out of the 2/8. >> My question is how does the S2 has [INDISTINCT]
the EID-prefix to eight, why did [INDISTINCT]?
>> FARINACCI: It came back in the Map-Reply. >> Yeah, yes, I know.
>> FARINACCI: It came back in--yeah. The question was, is the Map-Request was for a specific
EID, how did the ITR know that 2/8--the 0/8 was the granularity or the coarseness
and that comes back in the Map-Reply because these two guys know that they're 2/8. Scott?
>> SCOTT: Okay. So you can't [INDISTINCT]? >> FARINACCI: Absolutely.
>> SCOTT: The 0/8 [INDISTINCT]. >> FARINACCI: Yeah. Scott asked a question.
Do I have to sends back 0/8? And the answer is no. You can spend more specifics back.
And we refer to that idea as the Vince Shower idea. Vince took a shower one day, had this
great idea, and we refer to it ever since then as the Vince Shower Idea. You can--this
Map-Reply could come back with a prefix with different priorities and weights. It can come
back with a longer prefix. It should never come back with a shorter prefix. That's really
bad, right? And we mitigate against that. But it could--yeah, be more specific, because
you may want to say that the EID-prefix, this is the European region and this is the US
region for instance. >> [INDISTINCT].
>> FARINACCI: Yes, they're exactly. Other question?
>> Question? >> So, essentially, the--for a very busy load
sites, you're talking about this demand-based cache population, but essentially for a busy
sites like us, we have to [INDISTINCT] orange routers would have to have multiple tables
but basically [INDISTINCT] available, right? >> FARINACCI: Right.
>> Or most if 90% of what is the weight. >> FARINACCI: Right.
>> Right? So, the idea of--so we reduce--we definitely reduce for having table sites in
the core. >> FARINACCI: Yes.
>> And we basically would have pushed it back at the...
>> FARINACCI: Yeah, very good observation. >> Okay. And also isn't that sort of a vector
for pseudo [INDISTINCT] aside that I'm going to send you a mapping probably 0/32, like,
if you ask me for something, I assume I can [INDISTINCT] data.
>> FARINACCI: Let's hold the security questions to the end because I think I'll address all
of those. Okay. So let me re-ask the question so the people on the recording could hear.
So the first question was... >> It really gets--now for larger sites, did
you have to carry [INDISTINCT]? >> FARINACCI: Oh, those--so, yeah, yeah, that
was a good observation, is that large sites have to carry a large table. Will that table
be larger than a BGP table? Not clear, because you probably want people to come in to your
shortest entrance and give them shortest exit. So if you want--if you Google wants to talk
at one billion people, there is probably going to be a 100 routers talking to a 100 million
each or some power of two--or order magnitude difference. So I think that could be split
up by the number of systems and that will help. Let's see, you're other observation
was and I thought it was a good one was, is that you're really moving the problem from
large routing tables in the core to large routing tables on the edge. The answer is
yes, that's true for a big site like Google, MSN, and Yahoo, and that sort of thing. Not
true probably for the edge sites, right. And we have mechanisms where, maybe, Google doesn't
have to do the Map-Request in the opposite direction. We can talk about that in a second.
But, yes, it's definitely trading it off, but it's putting the state in the places where
they need it at the point in time and not putting it everywhere.
>> Because I think that's the key though because [INDISTINCT] EID to maintain [INDISTINCT]
depending on the traffic pattern. >> FARINACCI: It's depending on the traffic
pattern, absolutely. >> I have a question about data probe [INDISTINCT].
>> FARINACCI: I'm going to--let me introduce what a data probe is first so everybody else
can understand. And then you can ask that question at the end because this could turn
into a security presentation and I don't want that to be the case. Other questions?
>> JI: Yeah. So I didn't understand how... >> FARINACCI: Wait a second, JI. Go ahead.
>> You cover the [INDISTINCT] information in the Map-Reply...
>> FARINACCI: Yes, yes. Yes. >> Do you have [INDISTINCT]...
>> Yeah. >> [INDISTINCT] discuss that Map-Request of
each ETR... >> FARINACCI: I will talk about how the Map-Request
reaches the ETR on the next slide. JI, you're on?
>> JI: That's what I was trying to figure out.
>> FARINACCI: Okay. >> JI: [INDISTINCT] how to probate?
>> FARINACCI: I'll tell you in the next slide. One more question.
>> [INDISTINCT] and that would come back to the EIDs to--with all the [INDISTINCT].
>> FARINACCI: So the question was, is what if the destination site has multiple EID-prefixes
and a Map-Request comes in for, say, one of them does the destination site return all
the EID-prefixes? The answer is kind of, and I'll explain why. If in this case, if there
was nothing--if this was the only EID-prefix, you always return what's--what it matches.
And if the other ones weren't in the same power of two blocks, you do not return them.
You can have overlapping prefixes. And in those cases, you have to sometimes return
the overlapping prefix. In other words, this site could have a 2/8, but it also can have
a 2/16. And in that case, you have to return the 2/16 because the locators said if the
0/16 could be different than the locator site of the 0/8. So we just put in the last specification
that when they're nested, prefix is you return all of them.
>> [INDISTINCT] what about the overlapping [INDISTINCT]...
>> FARINACCI: In the case of different, you do not return all of them, just the one that
you care about, right. >> So why not just longer prefix match?
>> FARINACCI: Because if you go ahead--the question was, why not just do longer prefix
match? It's because if you do have Map-Request on, that matches the 0/8. And now
you go ahead and have--do another Map-Request and another EID that matches the 0/16. You
won't go Map-Request to 16 because you've got a map-cached on the 0/8. And you will
use the locator set from the 0/8 and not the 0/16. You got to make sure that the course
route doesn't screw you is the bottom line, is the short answer. You can't have the course
route match something when there's a more specific here but not in the map-cache. Let
me continue because the--I'll answer most of your questions on how things work. Now,
the big question is, and I'm surprised nobody asked, maybe you guys don't care, is what
happens to the packets that invoked it? What do you do? Well, there's really three things
you can do. You can drop the packet just like ARP does in the neighborhood discovery. You
can queue the packet. Well, go talk to your hardware vendors how much queuing are they
going to do in the data plane. Or you can actually use the data packet, forward it,
and use it as a Map-Request. And that's what Ed was referring to as a data probe. Now,
a data probe means it would follow the same path as the Map-Request, but if we'd sent
the data probe over to the ALT, then the ALT is no longer just the control plane infrastructure,
it'd be used for some type of data packets. And then you do have a packet ordering problem
because you'd be sending data probes on this alternate topology. And when you get the Map-Request
back, then, you'll send it, encapsulate it, you know, what happens there. So we have it
this spec because we think there's some datacenter applications where you don't need--like an
enterprise where you don't need a safe state or you may want to send the data robe just
on the default VRF and get--and trigger something back. In those cases where you can't lose
packets like storage applications, maybe you want to use the data probe. But in the Internet
case, we think that just drop packets; it's okay. Now, let's be clear about dropping packets
here. It's only for the first time, a first packet from any source on the left talks to
any source on the right. After that, there's caching and you don't have this problem, okay.
>> It's the--it's a number of packets transmitted to the device in amount of time that it takes
too... >> FARINACCI: The RTT time with of the Map-Reply,
yup. >> ...fall in place.
>> FARINACCI: Yup, just like ARP, just on the larger scale.
>> So [INDISTINCT] apply on the [INDISTINCT] there was a solution, some sort of solution
for the queuing version of this problem. And I don't...
>> FARINACCI: That's--there--well, he could be referring to various implementation techniques
that could be used. Now, are they practical and cost-effective to use? Another story.
Okay, so let's keep going. So let's talk about this mapping service interface so we can show
you how the Map-Request actually gets to the destination where it needs to do. So this
mapping service interface comes in kind of two forms. If you look at S2, it's this ITR.
This ITR could have this GR retunnelled to an ALT router, that's what the purple line
is. Okay. And when it wants to send this Map-Request for, it participates in BGP and knows
the next hop. In this case, it's just one--it sends a single-home to the ALT infrastructure
that it just sends it that way. And then this router knows how to get into its destination.
The other interface is that, as two can actually encapsulate this Map-Request and send it to
a Map-Resolver, and the Map-Resolver is attached to the ALT that knows how to get the packet
to the destination. Okay. So let's talk about a little bit more of the mapping interface.
Well, that's how the Map-Request gets under. But how do we know--how do we get it to the
site? So let's say we have this sort of scenario here where we have these three sites; here's
a 12/8, 11/8, and over there, we have 10/8 and also those locators in green and red respectively.
And let's say we have this ALT network that's set up. This ALT network can be run by service
providers, interconnect providers, registries, governments, third-parties, big hosting companies
that's start with the letter G, those sorts of places could do that. And what happens
is the first thing we say is we--this infrastructure also has these Map-Servers that are attached
to the ALT as well as well as the Map-Resolver as we talked about as well. And what happens,
each site will register this mappings to a Map-Service and they do it securely with the
SHA-1 authentication key that's shared. These two point-to-point; it's shared, no PKI needed.
Okay. So they send Map-Registers to these various Map-Servers. What the Map-Servers
then do--they're the map--okay. What the Map-Servers do is they inject those verified mappings
into the BTP ALT that runs here. And then at each level, this ALT, we aggregate it more
and more as we get into the core. So basically we built a topology with a distance-vector
protocol called BGP, so we could route a Map-Request from there to the site through this topology.
It's as simple as that. >> Is it something like Map-Servers or something
like [INDISTINCT] server or something like that?
>> FARINACCI: I have no idea. >> Okay.
>> FARINACCI: I don't know what it looks like. Everybody likes to describe solutions and
reference something else, and I never like doing that because then you have to go down
and say, "Why they're different? And why they're the same?" And you get into something that
turns out not to be a very fruitful conversation. Yes.
>> What does it recently aggregated? >> FARINACCI: This topology is going to be
built to map to the allocations. So if this guy has another power of two prefix that's
maps into here, he could register the maps, say, Map-Server. But if it's not--say, two
years later and he needs the more address space. He then will send the Map-Register
to the Map-Server that's part of that delegation, that allocation delegation and then, it will
then have all this 0/24 to this level that it can aggregate it to a 0/21. And then this
guy could take and aggregate and the 0/19, going this way.
>> It doesn't really have anything to do with the geographic [INDISTINCT]?
>> FARINACCI: Absolutely, not. Yes, absolutely not. It's probably going to be registry-based
because the EID-prefix will come from registries in certain clamps. So, if you get your prefixes
is at the right, you're probably going to have to connect to Map-Servers that are going
to be supported in Europe at the 0/24 level. Now, that doesn't mean that a US Map-Server
can't support it right. It could, but it's all logical, right, and you just--you would
just have to send your Map-Registers further on.
>> What's the difference between the Map-Server and a Map-Resolver?
>> FARINACCI: What--the question was, what's the difference between the Map-Server and
the Map-Resolver? I'll answer that as I keep going through the example, okay.
>> Okay. >> FARINACCI: There is the one who receives
registration request from the ETR so they can inject it into routing, okay. And then
the Map-Request--what happens is this Map-Resolver sit there and then when this guy over here
wants to send packets, which is down there that the Map-Resolver knows the next
hop to get the path the Map-Request to [INDISTINCT]. And what will happen is each--all router just
forwards these IP packets--forwards this IP packet along the path based on this distance-vector
protocol and then the packet can--the Map-Request can actually make it to the authoritative
guy. And then once he gets the Map-Request, he can just reply back to the source directly.
So the latency to get the Map-Request goes on this logical--hold on a second. The Map-Request
goes on this logical topology, and then once it gets to who's authoritative, the Map-Reply
goes back on the underlying network directly back. Did I answer your question? Yes, okay,
go ahead. >> JI: The point of VC Ops--for the VC Ops,
I can see you're a very handsome man, but I'd rather be looking at what you're pointing
at. So you're pointing to stuff off in the screen to your right.
>> FARINACCI: Gotcha. >> JI: Right.
>> FARINACCI: I apologize for that. >> JI: Yeah. Okay, the purpose of the screen.
>> FARINACCI: Gotcha. So let me review it real quickly. These ETRs here--do you see
my pointer? Or you want me to... >> JI: Oh, oh...
>> FARINACCI: We're going to get--VC Ops is at the table.
>> JI: [INDISTINCT] VC Ops. >> So, all right, you're looking at the slides,
right? Or are you looking at him? >> JI: I have--onto my right, I have the actual
slides, but I'd also be like to looking at the screen so when he's pointing at the screen
I know what he's pointing at. >> FARINACCI: How about you see this pointer
here floating around. >> JI: Oh, okay, that's fair enough.
>> FARINACCI: I'll use that pointer. >> JI: Thanks.
>> FARINACCI: So a quick review... >> JI: And I still get to see you.
>> FARINACCI: Yes, no problem. I don't know if that's a feature or bug, but... Okay. So
the ETR is basically a registry and they send a Map-Register message to their configured
Map-Servers for their mappings here. And the Map-Server is injected into this BGP structure,
the H1 eBGP over these GRE tunnels. So let me go back to the animation so you can see
it a little more clearly. And then let's just say when this ITR wants to be able to encapsulate
a packet to somebody at this site and it doesn't have a Map-Cache entry, it will send a Map-Request
on Now, it sends it to its configured Map-Resolver and that gets it--that gets it
to the infrastructure system that knows how to route it. And then the Map-Request go hop
by hop down here because this MS advertised 10/8 to the ALT when the Map-Register was--when
a site registered, and it goes hop by hop throughout. And then you take the shortest
AS-path. This can be--each of these ALT boxes could be an AS in themselves or you can have
topology in here and run an IGP if you wanted to. If you're an ISP that likes doing those
sorts of thing as you can. But basically BGP is being used as distance-vector protocol.
So the Map-Request can get to where you need to send real data packets. And when the Map-Request
gets to this point here, then, it says, "Ah, yes, I can give you this entry back. I know
the source was from this guy and I just send the Map-Reply back to the guy directly to
his"--the Map-Reply message is sent to the locator address. So it goes to--on the shortest
path on the underlying network. Better, JI? Okay, thanks.
>> [INDISTINCT] >> Yes.
>> And then the next hop on the map or the Map-Server?
>> FARINACCI: Okay. So the question was--good question--is what's in the RIB, in the ALT
routers or EIDs? The answer is yes for that. And the next hops are basically the IP addresses
that are on the tunnel interfaces. Okay. So this guy just says--this guy just says the
next hop to reach 10/8 is on this IP address which is this tunnel interface. And then I
just... >> But [INDISTINCT] that gets you to a Map-Server?
>> FARINACCI: Yes. The Map-Request gets to the registry Map-Server, yes.
>> Thank you. >> FARINACCI: And then this guy, Stevens--oops,
I'm doing the wrong thing. Okay, so this guy, when he gets the Map-Request, knows who's
registered to him and then he sends Map-Request. He load splits them across all the locators
that are at the site which are the ETRs. So we do get--so if you register into multiple
Map-Servers you can get the Map-Request load going to multiple Map-Servers. And then, each
Map-Server then can load split the Map-Request to all the ETRs that are at the site. So that's
how we are able to make the load and scaling work a little bit better. Good, Steven? Okay.
Go ahead, Ed. >> ED: What about the overall reply latencies?
Did that really [INDISTINCT] geographical function in here because it's the fact that
the first layer was altered at the cache [INDISTINCT] back up to the ETR.
>> FARINACCI: Right. >> ED: You could end up with significant amount
of latency of your geographic [INDISTINCT]. >> FARINACCI: The dominant latency is the
speed of light, and how far you have to go. >> ED: Yeah.
>> FARINACCI: Right. So what we did as an experiment--and you'll see this next week--is
my LISP routers at my house in San Jose but my EID space is at a RIPE space and we wanted
to see what it would cost for people to send me packets would have to go all the way to
Amsterdam to get my mappings, right? And we saw, you know, it's a typical thing that you'd
expect between 200 and 230 milliseconds was the latency. And yes, there are drop packets.
But once it's cached, it's okay. Now, we--the Map-Server spec does say, we can do caching
in the Map-Resolver. It's not evident yet that it's going to be worth it. Because don't
forget, once you--everybody's inclination to say, just cache because it will do it better.
But no, you don't want to cache this thing in a Map-Resolver because if that guy changes
his mapping, he might know all the encapsulators and he can update them. But he doesn't know
all the Map-Resolvers in the world that are caching him. So the mapping update problem.
A mapping update is defined to be--I'm going to change this locator set for this or I'm
going to change the priorities or weights for that, you know, use the mouse, thank you,
thank you. So you want to make sure that when these mapping updates change that you know
who to update and you have to do it fast. For datacenter applications, we have to do
it really fast. Go ahead, Steven. >> STEVEN: Okay. So, your [INDISTINCT] structure
is forwarding Map-Requests based on longer script of command?
>> FARINACCI: On EID, yes. >> STEVEN: EID? So, what if that takes you
to a Map-Server that is not--that did not receive a Map-Register request or a cutout?
>> FARINACCI: It won't because by definition, it wouldn't have injected the BGP prefix.
>> STEVEN: So I can't inject 10/8 from the lower at left and 10/16 from a different...
>> FARINACCI: Absolutely not because you're--we're making the topology map to that allocation.
We're not going to allow you to punch holes and be like the underlying BGP as today. See,
since it's all logical and you can point these guys to any locator, and that these tunnels
can be re-homed anywhere you want, we have flexibility without changing physical, geographical,
or topological structure, underlying structure. >> STEVEN: But then [INDISTINCT] you don't
have the notion of delegating [INDISTINCT]? >> FARINACCI: We do.
>> STEVEN: All right, then how? [INDISTINCT]. >> FARINACCI: Yes.
>> STEVEN: I gave you half of it. >> FARINACCI: You are who? Google?
>> STEVEN: I'm your ISP. >> FARINACCI: You're my ISP. Sorry, ISPs don't
get EID-prefixes. >> STEVEN: I'm the person who gave you half
of this EID... >> FARINACCI: Then you're AARON. Then you're
AARON. >> STEVEN: No [INDISTINCT]. I gave you some
of the EID specs. >> FARINACCI: Yes.
>> STEVEN: I like it so much. I give half of it to you.
>> FARINACCI: Okay. >> STEVEN: But you and I are forever entwined
because... >> FARINACCI: You made--you made the dependency
occur. If I want independence from you, the provider, I should go to him to get the prefixes.
We want to decouple these dependencies. We want to decouple the dependencies in the physical
link with the address linkage that you have. It's very important. If you--if we create
new dependencies here, we--the decoupling won't work, okay. Go ahead, Scott.
>> SCOTT: [INDISTINCT] so much we're on. Earlier, you mentioned the [INDISTINCT] the aggressive
aggregation of that [INDISTINCT] who's running that [INDISTINCT], how was that?
>> FARINACCI: So... >> SCOTT: You're talking about [INDISTINCT]
the EIDs and then you're going to enforce the kind of structure in the EIDs.
>> FARINACCI: Yes. >> SCOTT: How?
>> FARINACCI: We're--the boxes that are put up--and I have to keep a short answer. We're
not going to get through the presentation. We can talk about it as long as you want afterwards--but
the point is that there'll be these different hierarchical levels. And there'll be different
organizations that will manage boxes at each of these hierarchical levels. Those levels
are predefined to carve out the aggregation boundaries of that address space, okay? So
if you want to be at tier two, that means you're going to be at this level--at this
ALT level here, and you're going to be accepting 0/24s from Map-Servers and aggregating into
0/21s up. If you are at this level and you could--Google could be at both levels, maybe
Go Daddys is here and VeriSigns there, it doesn't matter. But they're going to provide
things at different levels. And they're going to try to create a service model or--now,
these things could be monetized pretty easily because these are stand alone PCs that could
be put anywhere. We think that the interconnect providers or third parties will want to sell
these things, just like DynDNS does, like Go Daddy does, that sort of thing. So these--this
isn't changing the infrastructure. This is adding new boxes to provide a mapping service
that can be monetized by various types of organizations. Service providers can get into
this game because a lot of people think service providers are going to be out of the loop
because you're just encapsulating and using the poor core service providers to just move
bits and do nothing else. But the service providers could sell this service. They could
package it with bandwidth. They could package it with other services and that sort of thing.
Let me keep going, okay, because we're--I'm running out of time.
>> JI: One quick question, quick question. >> FARINACCI: Yes.
>> JI: I promise this is going to be quick. So if I [INDISTINCT] a organization and I
decide to spin off or splint off some part of me, right now, I could just take the subnets
that though the more specifics that that organization is holding and announce them as more specific
so let them be on their way if that's a private address--if it's a...
>> FARINACCI: The way that it works... >> JI: ...for the address space.
>> FARINACCI: The way that it works in the LISP world is if you get those more specifics
and you branch off and you go to something else, you will then register those prefixes--register
them, not advertise them with a routing protocol--registered to a Map-Server that will take the 0/24s or
more specifics so the aggregation could be maintained in the core, that's all.
>> JI: Okay, thanks. >> FARINACCI: Okay, so let's get to interworking
before we run out of time. We have about 15 minutes or so. I mean, I could keep going
but I don't know what the schedule is. So what's important about interworking is how
does a packet exchange work between a non-LISP site and a LISP site? Again, pay attention
to the coloring here because a non-LISP site has locator addresses which means they're
addresses that are routable on the Internet. Where the green, the LISP sites, have green
addresses which are EIDs which are not routed underneath. So remember when a packet goes
from a non-LISP site to a LISP site, you got to always ask the question, "How does it going
to get there if there's not a route in the underlying network?" So we're going to show
how a packet's initiated from a non-LISP site to a LISP site, and vice versa, okay? We have
two internetworking or interworking mechanisms right now; A local/uncoordinated solution
where you don't need any infrastructure component to make this work and we called it LISP-NAT.
We're probably not going to push it very, very much further. We've done some prototyping
on it and we used it. But we think that, really, this new type of device in a network called
Proxy ITRs and Proxy ETRs will be used. And we think service providers and hosting providers
may want to do this, or interconnect providers, because this is a mechanism to attract traffic
and that's good for service providers. We can call--coined these PITRs and PETRs but
I will not burden you with that name. I'll call them Proxy the ITRs and ETRs which you
can imagine what they do. So interworking with NAT, basically, when a LISP site initiates
a connection to a non-LISP site, it's a EID going to a Well, that packet
obviously can get to the destination because 64 is underlying routing, so that just works.
The packet gets there with no problem. Now the return packet cannot get there, because is not on the underlying router. EID is not in the routing tables, right? So what
could we do? An EID address must be translated to a locator. So when you egress from a LISP
site, that has to be translated into a routable address. And we're showing right
here that's been translated to So when this packet is egressing out through
S1, S1 access a NAT, replaces with its locator, and sends the packet. That means
the return packet could come back because it's being addressed to, which means,
on ingress, it just maps it back. That's a kind of--not necessarily a traditional map
but it's an address one-to-one base NAT that could be used. Let's talk about the cool stuff.
Let's talk about building an infrastructure with Proxy ITRs. So let's say we have this
non-LISP site on the left-hand side that wants to talk to a LISP site on the right-hand side.
Notice that the addresses are in red and green which means is injected in the
underlying routing tables because it's already there today or nobody talks to that site.
We noticed that when the site on the right goes to LISP, it wants to withdraw
that from underlying routing because it wants to be a good citizen and it wants to decoupling
of addressing, okay. So, how will a packet get from S to D? Well, let's put these Proxy
ITRs in the infrastructure. There's all kinds of service models in placements where you
can put these--let's don't talk about that right now. Let's just say we have these Proxy
ITRs that will inject--I don't know if you can see in the middle--they're injecting 2.0.0/8.
What they're doing is and--hang on every word I'm going to say. These P--Proxy ITRs are
injecting a very coarse route for the EID range. You notice that, all the sites will
be in 0/16 or whatever they're masterlinks are, it doesn't matter. But it's going to
inject almost the default route, very coarse. So we're going to add a few routes so we can
save hundreds of thousands of routes. That's the idea. There's a little bit of techs, okay?
Now, why do we do that? It's because we need to attract packets from non-LISP sites. So
what happens when S wants to send a packet from his locator to that EID, we know that
the packet will go towards one of these Proxy ITRs. There's going to be an array of ITRs
out there, okay? So the packets will actually get to the Proxy ITR. The Proxy ITR will say,
"Ah, I'm going to look and see if 2.2.2 is in the mapping database. And if it's in the
mapping database, I know it's a LISP site. If it's not in the mapping database, maybe
it's routable underneath and I'll just send the packet." So in this case when it's in
the mapping database, he's going to do the Map-Request, Map-Reply dance like he does--like
he does. He's acting as an ITR at a site, but he's doing it for lots of sources, he's
a proxy. And what he'll do is he'll find out what the locator set is for this particular
destination and then encapsulates to the locator. The source locator is his locator in his infrastructure.
And that's how the packet gets to D2, D2, decapsulates because he's, packets
get delivered. That's what Proxy ITRs do. Questions? Yes.
>> Is that kind of a bottleneck? >> FARINACCI: Is that kind of a bottleneck?
No. It's on any cache service. You put a thousand of them out there and advertise 2.0.0/2 you
go to the closest one. It's as simple as that. >> What happen if one breaks?
>> FARINACCI: If one breaks? What happens if a Proxy ITR breaks? Well, the 2.0.0/8 goes
away and you go to the next closest 2.0.0/8. That's not what you meant?
>> No, that's not what I meant. >> FARINACCI: Oh, that's not what you meant,
that wasn't, yes. Okay, what did you mean? >> Well, I meant, like a soft break, right.
I mean, so when humongous packets [INDISTINCT] it's, you know, I mean obviously right, you
do something but do you... >> FARINACCI: Yeah, I mean, shit happens and
I don't know. You call your vendor and you say, fix it ASAP or I stop paying you for
routers, I don't know. I--that's an implementation specific. I know those happen in real life,
you're absolutely right. Steven? >> STEVEN: I think Proxy ITR on S?
>> FARINACCI: You do not have to configure the Proxy ITRs on S. They just inject packets.
See, those purple routers there are legacy routers. They don't know anything that's going
on. They're old routers. They're your site today. All they're going to do is look at
the destination address, and inject it into the network. And they will have a
route to it. It's just not going to go towards the destination. It's going to go through
the Proxy ITR. >> STEVEN: I mean, in the real world, there
might be a [INDISTINCT] 2.0.0/8 somewhere [INDISTINCT], right?
>> FARINACCI: That is a possibility, yes, but usually it's going to be more specific,
not less specific. If it's more specific, then it'll take the native path. And by the
way, if it takes the native path, then you can reach the destination. That means this
guy did not pull out his route. If this 2.0.0/-- gets injected and prefix comes this way natively,
so be it. Then you just don't use the LISP. At some point, you're going to pull the prefix
and you're going to use LISP. And we've seen some people on our network say, "I want to
play with LISP but I don't want to withdraw all of my prefixes. I only want this section
to do LISP." That's kind of, like what Facebook is doing now they say, "I want section to
use LISP but not that section over there." So what they do is they keep advertising their
more specifics in and they try to have the PTR do the rest, right? Now it's a little
bit dangerous because we don't want more specifics to be injected by the Proxy ITRs, right? More
question, go ahead. >> [INDISTINCT] the entire Internet? Yeah.
>> FARINACCI: Oh, thank you for my next slide. I can move on. Okay, so, my next slide, thank
you. So let's talk about when a LISP site initiates a connection to a non-LISP site
and then we're going to get into Steven's problem, right, and I'm going to solve his
problem. So let's look and see here, we have this source site and it's doing...
>> [INDISTINCT]? >> FARINACCI: Huh? Right. So we have the site
on the left-hand side, it's a LISP site. And it has--it's both doing a--it has IPv4 and
IPv6 EID-prefixes, right? And, oops, let me go back one. Oh, can't. And let's say that
this guy over here is a non-LISP site and the guy in the bottom is a non-LISP site.
It turns out that I wanted to show you two examples at one time. So the above sites,
IPv4 only and the bottom's IPv6 only. Now, what we want to do is we have these Proxy
ETRs. Now, of course, the source site wants to be able to send a packet to non-LISP sites,
right? So what happens is that source is going to inject it at What's going to
happen is this guy is going to realize that I could route it underneath, it will get there,
right? Because is red, it's in the underlying routing tables. But if this Provider
A does not like because it's not in the routing tables, it's going to uRPF-failed
and drop my packet. It's obviously not going to be an underlying routing, because if it's
an underlying routing, we haven't save the routing tables and now we're putting the EID-prefixes
into the core and we don't want to do that. So what we want to do is we want the ITR to
encapsulate to this kind of default or array of Proxy ETRs which is configured. So this
guy knows that he wants to send packet to with his own locator and he sends
it to the Proxy ETR. Of course, the Proxy ETR decapsulates and then can forward the
packet all the way. The reason we put this in place is because of the sun. The sun says,
"We don't want RPF to fail there." So, to hide--sorry, I'm walking up the screen. To
hide the source address, all you got to do is encapsulate it in a locator that this service
provider allow you to do. I do this right now at my house. I can get from my house using
IPv6 to And there's no IPv4 between me that's the next example I'm going
to show you. But I can also get to Darryl's house with IPv4 and I can load split my traffic
on engress from Comcast at AT&T, no matter--from the same host. It doesn't matter what my IP
address is, because that outer header is always a source address from the service provider
that the packet is going out on. This is good news. This is where the level of indirection
gave you a benefit even though there's cost with level of indirection was about.
>> JI: Wait, wait, wait. How is this different from doing NAT on S1?
>> FARINACCI: You can't do NAT easily when you're multi-homed. I'm going to keep that
as a short answer. >> JI: Oh, okay, I remember, right, right,
right. >> FARINACCI: Let's go to the next example.
>> Why can't you try... >> FARINACCI: Let me go to the next example
and then ask away. So now let's say S wants to send a packet to an IPv6 destination. But
now, this is an IPv6 LISP site going to an IPv6 non-LISP site. So what does it going
to do? It's going to send it to 2001:128::1 and it's in routable space. Now, it could
have the same sort of problem if it injects it into Provider B, it's going to drop it
on the floor. Guess what? It won't inject it into Provider B because Provider B is "IPv4
only" service provider. So you--no matter what you do with IPv6, it ain't going to go
anywhere. You could try to send it over the link. It's going to be dropped on the floor.
So what has too can say is I want to send it to a Proxy ETR but I'm going to use an
IPv4 locator Proxy ITR and encapsulate an IPv6 packet in an IPv4 header. We can support
all combinations four and four, six and four--which is this--six and six, and four and six. All
those four combinations are supported because they're just EIDs and locators. We don't care
what address family they are. So what happens here is the Proxy ETR gets the packet. He
decapsulates it and says, "Oh, there's this 2001:128::1. And my PETR is attached to this
provider Y which does support IPv6. I can open up an IPv6-TCP connection to Google today
from my house which is a LISP IPv6 site to Google which is a non-LISP IPv6 site. All
because my DNS queries are on your whitelist and you returned a quad-A record to me. Thank
you very much. Thanks to Eric, wherever he is. So Proxy ETRs are used for these two basic
features and uRPF has been a problem, Steven. And we think we can--now, what we can do with
IPv6 and we'll talk about this more next week with the use-cases--Okay, I'll admit it here
on public TV. The router vendor screwed up. We should have--we had 15 years to put dual-stack
into the core and we couldn't do it for whatever reason. All the OS vendors have put IPv6 in
their stacks. We have all the end systems that can do IPv6 so we have all this IPv6
on the edges and we can't get packets through the core. If you make those LISP sites and
you use those IPv6 addresses as the EIDs, you can use IPv4 as locators and jump over
to IPv4 islands, okay? So now IPv4 addresses will be used to address sites. IPv6 addresses,
which are huge addresses, large address-based, can be used to address every single particle
on Earth, okay? And you don't need a locator for every particle on Earth. You just need
a locator to get you close to the particle, okay? More about this next week. So I put
so--this animation--go back. These stars means that these two systems have an IPv6 TCP connection
to each other even though part of the path. The packet path is IPv4. So let's look at
the entire architecture one more time in one view. But so, remember we have the MRs and
the MS is over here on this side and we have the ALT thing. Now, what we're adding is the
CPE routers which are the legacy routers. The guys who were not [INDISTINCT] sites.
And then the PITRs--Proxy ITRs or Proxy ETRs that are in the infrastructure, these boxes
make up the entire LISP architecture and how you get access to the mapping database system.
These Proxy ITRs and ETRs are attached to the ALT because they must send Map-Request.
Proxy ITRs and ETRs could send Map-Request to Map-Resolvers too. It's just a Proxy ITR--it's
just an ITR for lots of places. But the functionality's no different than it being an ITR for a specific
site, same with Proxy ETRs. We just leveraged the basic machinery we already had. We didn't
have to make yet another device. Steven. >> STEVEN: So I'll ask my previous question
[INDISTINCT] IPv6. I'm working [INDISTINCT] and I have the tunnel service that basically,
you know, get everyone, gets people [INDISTINCT] calling service [INDISTINCT] no matter where
they are but enforcing these packets to traverse this some optimal topology that requires--the
packets actually [INDISTINCT]. If I could sweep all of that away and everyone could
have a tunnel, if I could say, you now have a LISP problems and you send your--the Map
register, the [INDISTINCT]... >> FARINACCI: Yes.
>> STEVEN: And I can now handout Map-Resolver answers...
>> FARINACCI: Yes, yes. >> STEVEN: An IPv6 like, LISP been able IPv6
so it's like could people get in that directly? >> FARINACCI: Yes, that's correct.
>> STEVEN: So that the data [INDISTINCT] it doesn't have [INDISTINCT].
>> FARINACCI: Yes. >> STEVEN: We have a lot of routing systems.
>> FARINACCI: So let me repeat all that for everybody on the call. So hurricane like electric
provides IPv6 service, I--I assume you meant Google when you said I or you meant some service
provider or something. I'll keep it that way. So what's your saying is you could deploy
these Proxy ETRs on that edge and you can have customers IPv6 do IPv6 LISP but they're
encapsulating v4 to you so you can decapsulate and deliver the packets natively to IPv6 to
the native IPv6 host. Yes. >> STEVEN: Or call it--if everyone who had
it, everyone, if we have a hurricane like your tunnel has a LISP problem.
>> FARINACCI: Right. Then they are just changing the type of tunnel, it's calling a LISP router
where they have a dynamic locator. And by the way, that Hurricane Electric Tunnel is
a tunnel to one point. You can give people four locators and they can load split the
traffic across IPv4 locators to get to the infrastructure. Go ahead, Dave.
>> DAVE: I think the [INDISTINCT] was--you do this with [INDISTINCT]?
>> FARINACCI: Yes, yes, yes. I didn't want to say that publicly but you can. Okay. So
LISP Security. This is--I don't want to give Voltaire this--credit for this. I want to
give Dave Meyer this credit for this, because he always says that whenever we try to build
two complex infrastructures. He says, "The perfect is the enemy of the good." So LISP
Security. These are the things we have on LISP, not too much, just enough we think.
ETRs use shared-key to register mappings to the mapping system. We use SHA-1 when you
decide what your EID-prefixes are because you call a registry and then you connect to
your service providers and find out the locators are, you got this binding. Now you go by service
from a mapping service provider and you say, "I'm going to register this binding to you.
The key is going to be 1, 2, 3, 4, 5." They can figure at the same way on the other end.
And they could also configure policy on that end to decide which locators you accept with
this verification key. So these EID-prefixes are not injected into that ALT BGP system
unless it's verified by this manual process. This is good. Manual is good sometimes. The
ALT BGP is also secured with peering authentication MD5/SHA-1 between neighbor peering things.
But, when we have local origin-type certification and stuff and security with sBGP for rides
we can actually use that too if you think the security needs to be put there, I don't
know. >> If you [INDISTINCT]
>> FARINACCI: The secure BGP stuff that's going out in the ITF, that's all. That's all
I'm referring to there. ITRs do not accept unsolicited Map-Replies. I hope this is addressing
your comment, Ed. And the point here is that you must send a Map-Request and you create
a 64-bit nonce that you remember, the Map-Reply must come back. We are using this basic concept
called route returnability. If I send the packet to Scott and he replies back to me,
the packet probably got to Scott. We are not going to address any man in the middle text,
okay? So you can comment on that after the presentation. ITRs do not accept coarser EID-prefixes.
That's really bad because right now if I think you're a 0/24 and you return a 0/8 to my Map-Request
then you're saying, "I'm going to be--send packets to these locators for all these other
sites, that's a redirection, okay? So we don't do that because the Map-Server can help you
here and you can use additional probing to find out what the real prefix is. As long
as you send Map-Request on the ALT, it is secured. The prefixes on there have been accepted
and are secured. So the length of the mask links for those advertisements are real and
validated. Map-Requests are rate-limited, okay? Negative Map-Replies can source-quench
EID sources. So if there's a source sending too many Map-Requests, the ITR can actually
stops any Map-Request for particular source and we have these Negative Map-Replies can
give you this actions saying, "I want you to natively forward a packet. I want you to
drop a packet. I want you to send a Map-Request." That's what--and the Map-Resolver can send
Negative Map-Replies and that is the mechanism to tell an ITR that the destination is a non-LISP
site because once you find out something as a non-LISP site, you don't want to encapsulate
because you don't know who to encapsulate to, and there's not going to be any ETR at
the other end. So it tells you to forward natively underneath. Cache management suggestions
are provided in this spec, we could talk about that offline. That's the amount of security
we have, no more, no less. So comments come later. I'm almost done, we could talk about
security. LISP and Traceroute. It's really important to find the entire path from source
to destination. So the Traceroute does go--gives you the path--the EID path from the source
to the ITR; the path between theencapsulator and decapsulator and the destination, it works
really nice for IPv6 because the unreachable message or the time exceeded message contains
the entire IP datagram. For IPv4, the original source is not in that datagram so you have
to do some fancy caching in the implementation to do that, but that's overbears to. We have
something called lig. It's equivalent to dig, the Domain Internet Groper but it's the LISP
Internet Groper. And it's a way to fetch the database mapping entries. And we have both
of the routers that we're shipping and prototyping now supported and Dave wrote a public domain
implementation that can run on Linux. And what this lig does is basically lig,
is an EID. So it's a liging for this thing. It's sending the Map-Request to that Map-Resolver.
And the Map-Reply came back from one of the ETRs at the site, in fact, it's the only one.
And here's the mapping database entry. Here's the prefix for it, here's the locator. It's
up. This is what the priority is. You can actually lig yourself and you can do it for
IPv6. This is basically saying, "Am I registered to the mapping database." This is me liging
at my house for my IPv6 EID. And what I get back is a Map-Reply for myself saying, "I
have three locators on Comcast and this 64-tunnel is an IPv6 locator." So it shows you how--it
doesn't matter what the address type is, okay? Okay, so that's it. Next week is going to
be really exciting because we're going to--so we've told you the--what is LISP. We told
you "How is LISP?" How it gets done? Next week, we're going to tell you why? And we're
going to provide real business cases and real problems that we're going to solve. And the
key thing you need to remember is that we are creating a level of indirection and we
can solve so many problems with the level of indirection. And that we don't need to
do hop-by-hop routing anymore. We don't need the core to join in on this sort of thing
that we're doing on the edges. That's what the level of indirection gives you. Now by
doing that, we can move lots of things around by keeping EIDs fixed. People like keeping
EIDs fix because there's no management of that address space. You don't have to DHCP
EID addresses as the host anymore. The only thing that changes is the mapping database
and the locators. And you don't have to inject more specific routes on the underlying network.
So we're creating all these movement type features without bastardizing or unscaling
the core, so to speak. So we're going to demonstrate--we're going to show you the dual-stack LISP network.
We have an ALT network that we built. We're in the third generation phase. And it's a
dual-stack so it supports sending Map-Request for IPv4 and IPv6. Map-Replies can come back
either way. We know when to send a Map-Reply back. If I get an IPv6 Map-Request over this
infrastructure, I know if I should send back a v4 Map-Reply or a v6 because I don't know
if there's an IPv6 path. So if I send an IPv6 Map-Reply back it'd mean I get there. So we
have mechanisms where you could hop over this homogenous address family type parts of the
network. We'll show you some contents and applications that are running on it and we'll
validating and testing some economic and service models. This third generation network is trying
to model these multiple service providers--mapping service providers and how you would connect
them. And we can show you the aggregation that you've been ask questions about next
week where the 0/24s get aggregated to 0/21s, and how all of that works. And we can see
if there's a real service that people can monetize and so forth. Go ahead, Scott.
>> SCOTT: So, yeah, I've been running a network for a mere part of the decade and I do de-peering
and [INDISTINCT] crash the entire idea [INDISTINCT]. Did I [INDISTINCT] mapping service and that
people [INDISTINCT] and get them all route to me and not happen to you [INDISTINCT]?
>> FARINACCI: So, Scott says I've been de-peering for a decade and the network's a mess. You
mean, deaggregating? >> SCOTT: Yeah.
>> FARINACCI: Okay, even deaggregating is what you've been saying. You're right. And
yes--somebody may have--and the routing tables are completely flat, right? There's a routing
table entry for Scott White somewhere which is--it shouldn't be Scott White, it should
be Google, right, or something like that. But yes--and then the question was--the follow-up
question was, "Can I build my own mapping database and provide service to people?" You
certainly could, yes. And you don't even have to do it with an ALT infrastructure. We're
going to show next week, well, one of the use-cases that enterprise will want to use
this. So say it like a Wells Fargo or any other bank will want to able to have all these
branch offices. They have thousands of branch offices; Home Depot, Wal-Mart, these retailers
have thousands of offices. And they want people to pick up laptops, move from one site to
the other and they don't want them to have the DHCP or anything. They want the same IP
address to be there wherever they move. And they want to build access LISP based on the
employ. So the EID is going to be static. This is a good thing. Static is good. It means
it's going to be your network name for the rest of your life. This is IP number portability
just like cell phone number portability. And so, wait, wait, wait. And so what's going
to happen is that they're going to build their own mapping database system as well. And we
think it's just going to be made up of Map-Resolver and Map-Servers. And since the ETRs are registered
to all the Map-Servers, they stay synchronized because of the registration mechanism. We
don't have a cache synchronization problem among those servers up there. So the answer
is yes, you could build a separate mapping service. Yes, go ahead.
>> The EID is good, 32... >> FARINACCI: Bits. The question was is the
EID 32 bits. The IPv4 EID is 32 bits and the IPv6 EID is 128 bits. Okay, so then, the real
meat is the use-cases. And we showed up to now some multi-homing and remote branch use-cases,
I just give you one, but we'll show you four datacenter use-cases which will be interesting
and we'll talk about LISP mobile-node. We're pretty excited about that. We are doing a
public domain implementation on Android and we're doing--we're building a lightweight
LISP implementation on Linux Android to show that we can take the concept of multi-homing
a site to multi-homing a LISP mobile node. That's going to be really exciting, I wish,
I mean, Dave is the leader of that project. Unfortunately, [INDISTINCT] next week but,
he'll be here in spirit for sure. Now that you can move a mobile-node around and change
its locators but keep its EID fixed, you can actually change--move an entire topology.
You may have a topology of VLANs, routers, VMs, servers, all with any EID-prefix and
you can actually move it to AT&T if they want to provide a Cloud service or Google. You
want to move it to Google, and all that has to change is not the internal structure in
addressing of that thing that you're moving but the locators that reach it. So there's
a lot of cloud computing use-cases that you can use here as well. Questions? That's pretty
much it for now but throw the questions. >> Is that ordered in any way?
>> FARINACCI: Is this ordered in any way? Questions ordered in a way. The main spec
the main multicast spec, the Map-Server spec, the ALT spec, the interworking spec, the order
is not in the way they were written. They're in the order that Dino typed them in, some
logical order. The mobile-node spec is there in under--it's still in the individual submission
and so is the lig spec. >> [INDISTINCT].
>> FARINACCI: Well, there's two types of packets in the Internet, you know, one that send 99%
at a time and the other that send 1% at a time. And you know which is which, right?
So we--multicast would be a nice thing to talk about because we're starting to believe
that trying to get just like it's hard to get ubiquitous IPv6 underneath. It's going
to be hard to get ubiquitous multicast underneath. Maybe Unicast-based replication at the ITR
is the best way to go and you build a bandwidth demand service. So, the sources could still
multicast at the site, but when you want to leave the site you can maybe Unicast replicate.
And we're thinking about can we do that directly with LISP or do you run this new protocol
called AMT that encapsulates multicast and Unicast, and then run LISP underneath that.
Ao those are advanced research topics for the smart people in the world, so.
>> Are there trust for a security? >> FARINACCI: All the security stuff are embedded
in each one of those. There's not a separate security draft. Please look at it and hack,
if necessary. >> JI: Yeah, I've--right, you're right. All
right. Sorry. You look at the screen where I appear, so...
>> FARINACCI: Yes. What do you want me to look.
>> JI: So, [INDISTINCT] some of that and I have quite a few security concerns. Where--do
I follow the normal light yet [INDISTINCT] authors or of the drafts or do you want a
different kind of process? >> FARINACCI: I would suggest you send comments
to, the working group LISP. >> JI: That's what I'm trying to avoid, getting
involved in the ITF again. >> FARINACCI: Oh. Oh, that's a bug, not a
feature. >> JI: Yes.
>> FARINACCI: You're more than welcome to send it to the authors. Send it to the people
on the center--front of this LISP and it'll be fine. Is there a better one to send it
to? >> [INDISTINCT].
>> FAINACCI: That's not a good one. >> Yeah.
>> FARINACCI: Okay. So, LISP Apps is one. You know, you can send it to one of us for--or
send it to me,, I'll make sure I forward it.
>> JI: Okay. Thanks. >> FARINACCI: We have--there are some public
LISP but it sounds like you want to go a little bit private and that's just fine. Thanks.
>> JI: Thank you. >> Yes, question. Can you share this slide
[INDISTINCT] later or...? >> FARINACCI: Oh, absolutely. I'll definitely
share the slides. And I think all three parts are being recorded so definitely. And if you
want a subsequent presentation were we deep dive in further, we can definitely do that
and we could actually log in the routers and show you stuff if you're interested. We just
want feedback. We want to learn more. We like bringing new blood into it because especially
guys that have your [INDISTINCT] experience because there's new things that we may have
not thought about and it's nice to bring fresh. Ones--see a lot of this stuff is pretty solid
in our mind and we can articulate it well. And if we can articulate it well then you
can ask us the things that we didn't--maybe didn't think about or why did you make these
tradeoffs? So the feedback's always useful. So we definitely encourage it. Oops, sorry
about that. Okay, thanks a lot. Oh good. >> [INDISTINCT].
>> FARINACCI: Oh, so the question was about cache and validation. So we have TTLs in the--you
ask a question. We have TTLs in the replies. We're defaulting them to 24 hours now. When
a negative Map-Reply is being sent, we default that to 15 minutes. The negative Map-Reply
is not saying go delete a map cache entry. It's saying that this--a negative map reply
is a reply that's saying, I have no locators for you. This is the action I want you to
do if you match this prefix. Drop, natively forward or send the map request.
okay, okay. I'm not--I wasn't sure. >> [INDISTINCT].
>> FARINACCI: Never, they're never unsolicited. No, negative Map-Replies. So what happens
is I'll send a Map-Request for the Google's IP address today for my home LISP router.
The Map-Resolver will look it up in the ALT. The only thing that's in the ALT routing table
are EID-prefixes. If it looks up that Google destination address in there and doesn't find
it, it must not be a LISP site. So the Map-Resolver send a [INDISTINCT] Map-Reply back to me saying,
"In your map cache, put this prefix," and it's a coarse prefix by the way, very coarse
prefix so that one map cache-entry could hit most of the non-LISP sites that tells me that
when I match that entry to natively forward and don't encapsulate, okay. Now--and when
an ITR is directly connected to the ALT, it can look in the routing table directly. But
when an ITR is connected to a Map-Resolver, which is a datagram, it's a loose connection.
You just send request to it like a DNS query. It doesn't have all the data locally, so it
has to ask the mapping system with the Map-Request to see if it's of LISP site or not. Did I
answer your question on--in validation kind? >> [INDISTINCT].
>> FARINACCI: Okay. Okay, thanks, guys.