LISP Part 1: Problem Statement, Architecture and Protocol Description

>>
Thank you for coming. I give you the man who needs no introduction so I'm not going to
give him one. Dino? >> FARINACCI: Thank you. Hello, everyone.
This is the first of a three-part series and we're going to talk about LISP not the programming
language but the network architecture and set of protocols. I'd like to introduce my
co-authors. Dave, Darrel, and Vince are sitting back there in gray, green, and black. Okay.
So, I think we're going to be able to fit this in one hour and so please go ahead and
ask questions at anytime. Okay, so this is going to be a part one. Next Wednesday, we
do part two: Mapping Database Infrastructure and Interworking. Since we are doing this
address splits, we have to map from one address space to another. That's going to be referred
to affectionately as the mapping database infrastructure. And, of course, we want interworking,
we don't call it transition but interworking. We want non-LISP sites to talk the LISP sites
and we'll talk about that next Wednesday. Part three is the most exciting part because
we'll talk about the deployed network we have where we're running approximately 60 boxes
in 10 countries now. And this is kind of a pilot test modeled network that we could possibly
put in to production later. We're going to describe the deployed network and the experiments
we ran over it and report on what our findings were and it continue to be. And then we're
going to go through a bunch of Use-Cases. That's probably the most exciting part on
how LISP could be used in branch offices, in saving address space, switching service
providers, moving virtual machines, moving roaming mobile nodes, there's all kinds of
Use-Cases that we will talk about. So, we'll start off with the basic problem statement
and what we're going to do is change the semantics of an IP address. And we're not changing the
values of it necessarily but just how you look at it and how you view it and where it's
routable, where it's not, where you need it to dynamically assign, and where you don't.
And then what is LISP? LISP stands for the Locator/ID Separation Protocol. We'll give
you unicast packet forwarding example, a multicast packet forwarding example, and then we'll
talk about the standardization status of LISP. And then, tell you what more specifically
of what we're going to talk in the second parts--second and third parts. Okay. So this--the
problem statement was actually defined at the IAB Routing Workshop in the fall of 2006.
This is really when the IAB, the Internet Architectures Board got together and said,
"We have to take a look at route scaling on the internet." So, the IAB--the problem statement
I'm defining here is what the IAB thinks the problem is and what we wanted to do as a solution
provider is to not only solve this problem but actually give features to customers, new
features that basically don't exist today that are allowing us to use the Internet in
different ways. So, what the problem statement is from the IAB specifically is that the rate
of routing table growth is of concern and has scaling impact on the Internet. Can we
reduce the size of the routing tables in an accelerated way in the short-term? And can
the current routing architecture support newer services like mobility, voice video, gaming,
virtualization and those URL references can give you more information. Now, this is--to
be extremely clear, this is not something to keep IPv4 alive forever. This is not something
only for IPv6. This can't--this solution can be used to transition IPv4 to IPv6. But the
way we view it is that the routing architecture is exactly the same for both address families.
You really, all you have is long as match routing to do any kind of traffic engineering.
So, to us, IPv4 and IPv6 is just a different packet format with different size addresses.
But everything else in the routing architecture is exactly the same. So the same bugs and
features are actually in both, okay? So basically, this is a routing table growth chart dating
back since 1989 going to just as of six months ago. As you can see, it's up into the right.
It was linear at some point, it's turns exponential. But the key is routing table growth is continuing.
Is this good or bad? Well, as a hardware vendor, we can keep throwing--you know, we love to
sell line cards to our customers but at some point, we want to give a value proposition
to our customers. And so, we have to be able to say smaller tables helps everybody. It
helps Cisco or Juniper; give new features without memory upgrades. We could download
fibs faster. We can bring our BGP peers faster. We can do Mib walks faster. So, small tables
help everybody. So one of the problems we have is just not new subscribers coming on
to the Internet that makes the routing tables grow but people that actually pollute it for
their own local purposes. People want to inject more specific routes into the routing system
because they want to be able to control which way packets come in when they're multihomed
in this case, right--in both of these cases right here. Really, routing's only tool is
this blunt instrument called longest match routing. And if you send it--if a routing--if
a router has a 0/24 and a 0/8 and the destination is routing to matches to 0/24, it would use
it over the 0/8. 0/8 is only used when the 0/24 is removed from the routing table. So
what happens here on the left-hand side, we have a site that's multihomed. It has addresses
that are signed out of provider assigned space, in this case Provider A. And Provider A's
block is 10.0.0.0/8 so usually the addresses out of here are more specific. Now what happens
is if the 0/24 is advertised into the system and then this provider just advertises 10.0.0.0/8,
all packets that are addressed to any systems that are in 10.1.1 will come in through this
link here. And what we find is these links are getting hot, 100% utilization and these
are completely idle. So for this system--for this AS to be able to get packets on both
pass, it has to inject a 0/24 here into an area of the network that can aggregate that
0/24. So which means a 0/24 has to go in everybody's routing table. There is a local benefit here
at global cost, okay? And not only that you inject the route this way and if you just
injected the route this way then packets will come in on this link and not from Provider
A. So you actually, you have to inject the 0/24 in both directions and the provider has
to inject a more specific from his aggregate, and this is adding to the routing table size.
Now, if you come over to the right-hand side, this is a provider independent prefix which
means this side went to a registry and said, "Give me a prefix that's independent of the
service providers I'm connected to. I'm not going to ever have to renumber again and I'm
just going to inject 15.0.0.0/8 through both of my providers and both of my providers are
going to propagated it, okay." The default IPv6 allocation policy is to give you PI prefixes,
which means we're going to have a flat routing table and the capital I Internet because everybody
is going to have addresses that don't map the topology and therefore, we can't have
aggregational hierarchy and scaling. So, this is the real problem and we want to be able
to bring back the aggregation of addresses again so table stays small. Questions? So, what we want to do is we want to separate
ID from location for the IP address. Today, an IPv6 and IPv4 address have this overloaded
semantic. The 128-bit address here, bit means both ID and location. So, if I'm going to
send an email message say to Scott at Google, I can open up a TCP connection. The address
is already determined on where Scott is because where he attaches to the network defines what
his address is, okay? That's actually his location topologically. Now, Scott goes home
and I want to--and he stops at Starbucks and I want to send him an email message. Now,
I have to send it to Scott at Starbucks. His location change but the person I'm talking
to has not changed. So, since the location changed the ID must also change. I must reset
my TCP connection and then reestablish it to get to him and then when he moves home,
I have to do it again. Wouldn't it be nice if we can separate the ID and the location?
One way you could do it is take the low-order bits of the IPv6 address and call it an ID.
And if TCP would do the pseudo-header checks on only the low-order bits we can make this
work. But it does not. When IPv6 was invented it said, "Use the entire 128-bits." The high-order
bits can be used to say where you tap into the topology and there's enough bits there
where you can do enough aggregation at multiple levels. You want enough bits on both sides.
You want it on the ID side so you can have enough connections that are opening up to
a server, millions of connections. And you want enough bits on the left-hand side because
you want to do aggregation. But for IPv4, we don't have enough bits for either one.
So what we want to do is we want to add another address. We can't change the IPv4 header format
for that's a non-starter. So what we'll do is we'll use encapsulation and when we put
another header on to a packet, the addresses that are in the outer header will be locators
and the addresses on the inner header will be these things called EIDs. So, since we
can't separate it like this, what we do for LISP is we say that endpoint IDs, we call
these addresses EIDs that are assigned to hosts and routers and switches that are at
its site are basically 32-bits in length and 128-bits in length. Now, what's nice about
that is we know IPv4 and IPv6 addresses are power of two entities, and therefore, we can
aggregate even EID prefixes. So if we have a mapping database that maps from EIDs to
locators, we can do that in a scalable way as well. And of course, the locators are still
32-bits and 128-bits, but those are the things BGP will route on in the core, okay? That's
the idea. So this is how the addressing would kind of break up. Well, in the last example,
we said this was 10.1.1.0/24 that site is still keeps that same prefix, we'll just call
it an EID prefix and it does not get injected into the core. As you see throughout this
presentation, whenever you see a green address, it means it's from the EID space. When you
see a red address, it's from the locator space. But here, what we're showing is that 10.0.0.1
is the locator or the IP address of R1 that's attached to Provider A. So this address, this
locator address, comes out of Provider A's allocation and this address and R2 comes out
of Provider B's allocation. So it's already--these are covering routes. So you can see that the
Provider A and Provider B only has to advertise its aggregates, right? And then the addresses
here never appear in a destination address of a packet that's flowing throughout this
network, okay? Now over here if you come to the 15.0.0.0/8 where it was PI, same thing
goes, okay? And we'll explain how this works in a second. So that's the fundamental idea
of breaking up the address space. Now if you keep EID's fixed, you don't have to renumber
ever again. If you change from Provider D to Provider F or whatever, all you're changing
is the point-to-point link and the IP address on the PEC interface is the only thing that
has to change. And guess what? If you had these PA addresses that service providers
were giving out, they could actually reclaim all of them because now what they only have
to address is that point-to-point link on the other side, on the CE side. So now there's
more addresses, more IPv4 addresses to address sites, not devices at sites. So now the address
space could be used more efficiently. And that's why we get the reaction from people
like, "Oh, you won't need to go to IPv6 because of that." Well, that's not certainly true
because we want IPv6 to still number all the devices in the world and that will exceed
to the 32 real soon now, okay? Now by not having to renumber, you can actually change
service providers of a stationary site changes service providers, it's actually changing
its location, because it's tapping into a new part of the topology where the address
dictates where it is in the topology. So you can change service providers or you can take
a virtual machine or a server or a laptop from one site and move it to another site
to keep the exact same IP address, we call it an EID, and the only thing that changes
now is the locator. So we have all of this movement. You can actually take large topologies,
VLANs, the IP subnet addressing of a datacenter, and move it into a Cloud and the only thing
that has to change are the locators that are associated with that EID prefix. So just remember
that EID prefixes and EIDs that are assigned to host don't change. They're static. You
can even turn off DACP if you want to for assignment. So you have a name, you know,
scott.google.com, is his DNS name. That's what people use. But it'll map to an EID which
is a network address that he will keep for the rest of his life. And it's--what we're
doing here with IP is the same what the cell phone industry did with cell phone number
portability. This is IP number portability now. So a change service providers, you can
roam--have roaming handsets, you can move virtual machines, you can relocate infrastructure
in the Cloud. And we can do all of this while keeping the core clean and reducing the size
of the routing table. That's the dream. That's the hope. So LISP, it has some recursive properties
like the programming language but it doesn't have as many parentheses. But it has some
network layer headers that you could put on it. But it's basically a network-based solution.
No changes to host whatsoever. We mean that, and we've proved that, and we can--we'll continue
to prove that. No new addressing changes to site devices. We don't want you to have to
renumber your subnets and all the addresses at your site. We want those to be used. And
those are going to be called EID prefixes that are used in your IGP, your IGP doesn't
have to change. Very few configuration file changes, that means we think the sweet spot
for LISP is to put it on the CP routers at the site. And what we're trying to do with
the ISR product line at Cisco is say, "You just have to load a new software version and
we can then do LISP encapsulation and nothing has to change on the sites side and nothing
has to change on the core side to make this happen, because incremental deployability
is imperative." That's all there is to it. We really want this to be deployed. And you
can do v4 and v4, v6 and v6, v6 and v4, v4 and v6, all four combinations need to work.
More to the point, maybe three out of the four need to work. So this is how it would
look like. The packet format on the left-hand side basically is showing you four-on-four
encapsulation. But what you'll see over on the right-hand side is the host will build
this packet right here and put an IP header on it. And when it inserts addresses there,
we're just going to call them EIDs. It's the same 32-bit values that puts in today. The
source address is from either DACP or an IF config command. The destination address you
got from DNS. We just call it an EID but the values are exactly the same. The packet then
makes its way to the edge and then there's a LISP router on the edge that adds another
header on it, and those are locators. So you see the locators are out on the outer header,
and the EIDs are in the inner header, and this is the LISP encapsulation. We use UDP
encapsulation because we want link aggregation groups that exist between two core routers
in the core to be able to load split traffic along a number of links. So it's really important
that we use UDP because the destination ports are well-known port, but the source port will
always vary based on a 5-tuple hash of the inner header, okay? Note that you can have
IPv6 EIDs over IPv4 RLOCs. And when we show you a use case, I will show you how, at my
house, which is a LISP site, I could connect to IPv6google.com, which is a non-LISP site,
and there's no IPv6 connectivity between my house through Comcast and my house through
AT&T to Google. With that, we were able to get that to work. So you have to wait two
weeks for that. So let's look at a unicast packet forwarding example. So here we have
two sites. They're both multihomed, kind of a mirror image of each other. Let's say they
both have PI prefixes. EID prefixes out of 1.0.0.0/8 and 2.0.0.0/8 respectively. And
we call these things, ITRs are the encapsulators and the ETRs are the decapsulators. They stand
for ingress and egress into and out of the tunnel, okay? And we're going to show an example
here that S is going to send the packet to D, okay? And what we show here is that the
only thing that has to change to make this work is that S1, S2, D1, D2 are modified to
do LISP, but everything else stays the same. So S will send a packet of D. First does a
D.abc.com, it's a single A record back, could get a Cloud A record back, it doesn't matter.
And then injects this packet to 2.0.0.2. It puts the source address 1.0.0.2 out of its
EID space just like we mentioned before. Let's say it's a TCP SYN packet because it wants
to open its connection. Let's say that this source site has an egress policy of shortest
exit. And let's say S is closer to S2. Let's say, S1 and S2 are injecting the default route
and so S is going to find--its packet is going to make it to S2. We introduced this new data
structure called the mapping entry or a map cache entry. This is an entry that sits in
a data structure. It can be implemented many different ways. But it's the longest match
lookup as well. But this--let's say this entry is already cached. We'll wait until next week
to say what happens when it's not cached, okay? But for now, let's just say it's already
cached. So the 2.0.0.0/8 is basically saying this site has two locators, 12.0.0.2 and 13.0.0.2,
where 12.0.0.2 is its PEC connection to provider X and 13.0.0.2 is its connection to provider
Y. Note that the priority in weights are your only two parameters that you'll use tap policy.
It's these ETRs that are authoritative for this mapping, okay? Everybody is authoritative
for their own mapping. The mapping database is completely distributed across the entire
Internet in the sites where they need to be. Kind of like a DNS server for your own domain
name, okay? Now this site has decided that priority one and one for each locator means
that once active-active on ingress. This guy is paying for those two links. He wants to
control which way packets come in. So what he says is, "I want it to be active-active
and I want the late weights to be 50-50." So anybody who's encapsulating to me, will
you take your flows and 50 percent of them send it to this locator, another 50 percent
send it to 13. Okay. Yes, question? >> So what's [INDISTINCT]?
>> FARINACCI: Yeah, the question was is this looking a little bit like MPLS and the label
kind of looks like the locator and the private address looks like the EID. So, it's a little
bit different in MPLS because it's done end-to-end. Typically, MPLS is done in one administrative
control which is within an AS and the labels are reswapped hop-by-hop. Where here you would
argue that the locator is a label but it's an outer IP destination address that's put
on at the edge and decapsulated at the other edge. So, the core just think it's this IP
packet that it needs to forward. It's forwarding it from site S to site D. Once we inject the
packet into the center, you'll find out that the routing, because of the level of indirection,
the guys in the center are not routing a packet to D. They're routing a packet to the site
of D, okay? >> Same question. So, it looks like that you've
got a little [INDISTINCT] you are global routable, right?
>> FARINACCI: Yes. >> But, you know, IP the subnet, whatever,
the IP, right? How do you [INDISTINCT] not everyone knows.
>> FARINACCI: So, the question was it looks like the locators are globally routable, and
that's a true statement, and it looks like that the EIDs are not so how do you distribute
them to the rest of the world? That's what the mapping database infrastructure will be
used for. And we'll talk about that in part two next Wednesday, so please show up. So,
what if this guy wants a different policy depending on who's--where the source packets
are coming from. Let's say, D1's in Europe and D2's in the US. Let's say, a map request
for our source that's in Europe comes in. These ETRs can say if there's a European source,
send it 1 and 2 where 12 is the higher priority one and 13 is the lower priority one and it's
active backup. Or if the source is coming from the US then make D2 be the primary path
and D1 be the secondary path. Or if it's coming from the source and you care about this segment,
the destination is in Europe versus you can also do it based on destination as well. This
is what's in the mapping database from the ETR's point of view. But when they send a
map reply back so the ITRs will cache, they can cache--they can reply back with any value
of priority and weight. Now this is really hard to do today with BGP. You need to have
a PhD in BGP to do this. These are simple rudimentary parameters here where you can
do multihoming quite easily with LISP, okay? So, now what's going to happen? The guy is
going to do a longest--the S2 is going to do a longest match up--longest match lookup
on 2.0.0.2. It's going to find this entry. It's going to see that priorities are equal
so it's going to do 5-tuple hash on the inner header so 1.0.0.2, 2.0.0.2 protocol number
and UDP and TCP port numbers if those--if it's a TCP or UDP packet and then it's going
to select, let's say, 12.0.0.2. So, it goes ahead and prepends a header. The destination
address is set to 12.0.0.2. The source address is the address, its locator address, on the
PEC link which is 11.0.0.1, then the packet is basically injected into the core. What
happens is B gets the packet and says, "Where am I routing this packet?" I'm routing this
packet to a customer of provider X, not to D, to a customer of provider X. If I'm running
my BGP best path selection, the policy now is based on, "How do I route to that last
top AS?" that's directly connected to the client. So the policy to provider X will still
be used, but the policy to the endpoint will not. That's either a benefit or a cost to
level and direction, you be the judge to that. But what happens is the packet will then be
sent on the shortest path, shortest AS path to provider X. Provider X will have a more
specific route because it's a customer and we'll route it through its AS and the packet
will appear on that link. Of course, decapsulation is simple, it's just like a GRE tunnel or
IPsec tunnel is that D1 says, "Ah, it's addressed to me. I stripped the outer header and then
I do around lookup on the inner header." My IGP says it's one of my internal-facing links.
Send the packet all the way to D. So this is basically a tunnel. It's not a tunnel that
you either love or hate in IOS we say interface tunnel zero; this is the source's destination.
These are dynamic encapsulating tunnels where there's a routing table so to speak that's
used to put on the outer header. And then this mapping between EID prefix and a locator
set is done in the mapping database infrastructure, okay? These locator set stays pretty much
static which means if 12.0.0.2 to 13.0.0.2 go down or the path from S2 goes down. They
are not removed from the mapping entry because we don't want large churn on the mapping database.
So locator reachability is kept out of the mapping database. And we have mechanisms that
do that which I'll talk about in a couple more slides. Questions on this example?
>> Why the tunnel--the endpoint or the router? >> FARINACCI: The router. S2--S1 and S2 prepend
the header. They are the LISP routers that put the header on and take it off. The host
don't change. If the host had to do it, we would have to modify the kernel to be able
to put do new list encapsulation. We can't do that. Question again?
>> Does the mapping entries have TTLs? >> FARINACCI: Does the mapping entries have
TTLs? The answer is yes, they have TTLs. They're defaulting to 24 hours now. We think if you
implement an ITR functionality on a mobile know that they'll have to be much smaller.
But there's also mechanism to say that now, if this guy had a D3 to a third service provider
he would add a locator that there's a mechanism to do mapping updates to all the cachers.
And we'll definitely talk about that as well. Next question?
>> [INDISTINCT] >> FARINACCI: Yeah, good point. The question
is, why can't the source choose which locator it uses versus to having the destination?
It turns out that if you have enough locators, you can set a lot of high-priority ones and
that could allow the source to decide within the high-priority ones which ones they would
want to use. And the low-priority ones are there because of only all the high-priority
ones go down. Then you switch over. But we want to be able to--the LISP specification
says we really want to give the ultimate control to the receiver site. But within a certain
bounds, there are some flexibility for the source site to be able to select a locator.
Yes? Yes, question? >> I mean this is a policy question but how
do you ascertain for all of that? Like say I have a software load on the ITR. I decide
that, you know, right there I didn't really want to listen to AT&T's crappy engineering
signals if I could get something better. >> FARINACCI: They won't be AT&Ts. They'll
be the site that connected AT&T. >> Yes, yes. It's downstream, right?
>> FARINACCI: Okay. >> But I mean, so I mean--it seems to me that
you can't--could only postulate that that policy would be, you know, enforceable to
process a subsection of your, you know. >> FARINACCI: Right. So, the question was--is
even though the protocol specification--and tell me if I characterized it right--The protocol
specification says the ITRs will obey the mapping on any implementation could do whatever
its want and actually disobey it. Now, this is true. This could happen with a lot of protocols.
DNS is a very prime example of how TTLs are ignored, right? What we want to do is first
and foremost, from a protocol designer's point of view, we say this is how we want it to
work and this is a well-behaved system. Let's document it that way and let's have conformance
testing that the implementations do that way. Then entropy sets in and practicality sets
in and what you say is going to happen. So let's hope that we don't get there for a while
but let's see what happens. Yes, go ahead. >> JI: Can you hear me?
>> FARINACCI: Yes, I can hear you. >> Is it a good time to ask high layer architecture
because you said you have more slides? >> FARINACCI: I definitely have more slides.
Is it related to data forwarding? Ask the question and I'll--now or we'll take it later.
>> JI: Not direct. It's just that--by the way, can you--I don't know if you can see
me. This is JI. I've been in mobile IP back in 1990-91.
>> FARINACCI: Yeah. >> JI: Vista and other stuff as well. So,
this looks like the green boxes are really care-of addresses and--or if this looks like,
I don't know, VIP address decapsulation from the circa '92-'93 from one of the next generation
IP and [INDISTINCT] efforts, or it looks like 8+8, if you remember that? So...
>> FARINACCI: Okay. Can I respond or do you have a question?
>> JI: Yes. No, well, the question I'm trying to ask is what's important here is not really
the packet format. This is encapsulation. I think what's important here--and maybe,
I don't know why you haven't put enough references on it, the important thing is how you do the
lookups. Whether you do it with some particular kind of encapsulation, it's not particularly
relevant. For all we care, this can be [INDISTINCT]. The important thing is how you select the
right addresses and how you prevent some other attacks that suddenly become feasibly here.
All right, I'll shut up now. >> FARINACCI: Right. So, I have many responses.
The first one is take any technology and it always repeats itself every 10 years.
>> JI: Right. >> FARINACCI: So this is not supposed to be
necessarily innovative. Were using techniques that are well-known and safe and being conservative.
This is, yes, an encapsulation proposal. The D1 and D2 addresses in mobile IP terms are
called care-of addresses but those... >> JI: Yeah, they're care-of addresses.
>> FARINACCI: Yeah, that's fine. They are really--a care-of address basically says when
a mobile node moves to a certain topological location that it will have to get packets
to it, it has to get it to that part of the topology. So, yes, it's just another name,
we call them locators because it's locating where the ID is, where the device is or where
it moves to. >> JI: All right. I mean the concept of locator
versus ID split has been around for, I think--for as long as I have been doing networks. I mean
that's the fair amount of time. >> FARINACCI: Yes, you're right and nobody
has built an engineering solution based on it, Noel Chiappa is working with us.
>> JI: I have [INDISTINCT] that too, yes. >> FARINACCI: He's [INDISTINCT] one of the
inventors of it and we are just doing the engineering effort to make it happen. I don't
think if you're assuming that we're telling you this is a brand new innovative thing,
we are basically saying we're taking the ideas of past and putting it into engineering and
trying to build real protocols and to explain how the protocols work, the double is definitely
in the details, so the packet formats are really important.
>> JI: Okay. So, wait. I think that what, maybe I missed but what you didn't emphasize
in your talk which I think is the real important part is that this is a very concrete engineering
effort with particular goals in mind as opposed to, "Oh, here's another networking architecture,
let's send it to [INDISTINCT]." >> JI, we're half an hour into the talk, and
it's a three hour talk. >> FARINACCI: Right.
>> So we should... >> JI: Oh, well, but I've read about in the
[INDISTINCT]. These are some questions but--all right, I'll shut up now. Sorry.
>> FARINACCI: If you stay through the three hours, I will answer all your questions, I
promise. And if I don't, I'm sure you'll tell me.
>> JI: I'll be here. >> FARINACCI: Okay. So...
>> JI: Okay. >> FARINACCI: In fact, you should tune in
for part three because we talk about how LISP mobile node is quite different than mobile
IPv4 and mobile IPv6, and has very interesting properties and features that have never been
implemented before. So we will talk about that. And by using Locator/ID separation,
that's the only way you can achieve these sort of features. Any other questions on Unicast
Packet Forwarding before we go to Multicast. Steven?
>> JI: Okay. There's another question which–is a limited to security related which is--we've
had a very hard time convincing ISPs... >> FARINACCI: Wait a minute, hold on. You
are second in line, there's somebody ahead of you in the queue. Steven, go ahead.
>> JI: Sorry. >> STEVEN: So, good question. One, we don't
need to keep [INDISTINCT] an ITR to come on different ways.
>> FARINACCI: Correct. >> STEVEN: Can you make an interpretation
regarding the implementation that all packets have been closed have been invented at the
same ITR. Or, did someone created a [INDISTINCT] packet and [INDISTINCT].
>> FARINACCI: Right. So the question was–-is, does the ITR, the encapsulator keep per flow
state and how do you maintain packet ordering? So it's just like doing an ECMP look-up or
EtherChannel, the 5-tuple hash will always pick the same locator all the time and packets
are always encapsulated to the same place. >> STEVEN: Is that guidance to the implementer
or is there something...? >> FARINACCI: It's a must in the specification.
So, if we--if you do some of the things that were--we were talking about over here and
violate that, you're going to pay for the non-spec compliant stuff. Any other questions
on Unicast Forwarding before we go to something even harder?
>> JI: Can I ask my other question now? >> FARINACCI: Oh, yeah. Sorry, I forgot you.
Sorry. Really, [INDISTINCT]. >> JI: Sorry. So, we've had about 10 years
worth of travel convincing ISPs to fill their source addresses from at least a customer
phasing ISPs of some ISPs to filter source of addresses that should not be appearing
in the IP packets. And suddenly here, we're sending an unauthenticated packet to an ETR
and with some unauthenticated source EID that is just going to go away. Can you comment
on that? >> FARINACCI: What you're referring to–-so,
the question is, what happens if you send packets in the network with unauthenticated
sources via the source locator or source EIDs... >> JI: Right.
>> FARINACCI: Is that the correct question? >> JI: So, yeah, and there is no authentication
that they can see here unless some more is coming later on.
>> FARINACCI: Right. So, most service providers you something called Unicast RPF were they
check to see if the source address is in the routing table and that a particular stub site
should be able to source that. That will still happen on the locator address and still will
be used. In terms of authentication... >> JI: How do you know that? I mean, the--who
enforces that? Is it the ETR or the--the ITR is the culprit here.
>> FARINACCI: The PE router on provider A will make sure that packets only come from
10.0.0.1 that comes over that link. >> JI: But what if the ITR of the router that's
one for example, is a compromised router or is a black-hat ISP in Russia, that's trying
to send in bad traffic. >> FARINACCI: The answer is your SOL.
>> Okay. So, no change from when we were... >> FARINACCI: Yes. If we put in all those
security hooks, we will not get this deployed. To quote Dave Meyer, the perfect is [INDISTINCT]
together or whatever. >> JI: Storing [INDISTINCT] lies...
>> FARINACCI: Yes? >> So, what [INDISTINCT], right, did not occur.
>> FARINACCI: I didn't hear the question. >> So not to you--I don't mind you put another
[INDISTINCT]... >> FARINACCI: Yes.
>> Then all type of the efficiency... >> FARINACCI: I'm going to talk about that
in two slides. The question was, what about packet efficiency? And that's how do you handle
a larger MTU-sized packets? We'll cover that in two slides. Last question?
>> I just want to comment with the specifications [INDISTINCT]...
>> FARINACCI: Hold on a second. Darrel, one of the co-authors wants to make a point and
you will not get captured unless you come up here and speak in the microphone.
>> LEWIS: Well, I just [INDISTINCT]... >> FARINACCI: Okay.
>> LEWIS: Just [INDISTINCT] is the best specifically in the specification [INDISTINCT]...
>> FARINACCI: Okay. Darrel says that, uRPF is specked out in the LISP specifications.
Please refer to them and you'll get all the details you need.
>> JI: Okay, thanks. >> STEVEN: Next slide.
>> FARINACCI: Steven says go to the next slide and he's the boss and that's what we're doing.
Okay. So what happens if there's no map cache entry in that ITR in that encapsulator? Wait
until next week. That's the mapping database infrastructure stuff. And it's very interesting.
So let's talk about Multicast Forwarding and we'll go through this pretty quickly. But
what's important to note here is if you want to do Multicast, inter domain Multicast, or
even if you want to do Multicast over LISP in an enterprise network, if that's your infrastructure,
you can't have the Multicast design goals counter what the design goals were for Unicast.
So you can't put EID, G state in the core because that EID Unicast state is not in the
core, okay? So we just have these two different types of Multicast states were we prepend
these trees together. The S-EID, G, the S-EID is the source host. So if you joined to a
host. That would be that. G has no--the group address has no ID or location semantics. It's
really an opaque value. So we can actually use G in both cases. And when the state is
in the core, we call it S is the RLOC which means it's the--going to be the encapsulator.
I'll show you how that works in a second. So we have these two sites on the bottom which
are receiver sites. We have receivers one, two, and three. That site out to the right
is not a receiver. We want to show you that data packets don't go there because they're
not joined to the group. S is going to be a Multicast source; you see its IP address
is 10.0.0.1 out of EID space. The green boxes are PIM routers at the site and the blue ones
are PIM routers that are in the core, okay? Sorry about this, but I'm going to have to
use–-so what happen is R1 will send a regular join like it does today. Since it's an external
source, it'll make its way to the ETR R11. R11 will then, say, I need to do a mapping
database look up on the EID just like we did when we wanted to send a Unicast packet. I'm
going to get a locator set. Then I decide which way to propagate a new type PIM join
called the RLOC, G to S2. I could hash on the sourcing group to decide which one to
send it to. And the fan-out could be inside the source, the source site, or it could be--the
fan-out could be in the core, depending on how routing for the locator takes you. What
you have to do over the top is send an S-EID, G Unicast it from R11 to S2 because you want
the tree to be setup in the source site. So you have that, sort of--that happen. Then
the same thing happens in the other site down here on the right-hand side–-oops, and then
you see that the other S2-RLOC, G is sent hop-by-hop all the way to S2. You see where
the merge point is, that's going to be a replicating point in the core. Unfortunately, the next
is not working. And then what happens is that guy does the same thing. It turns--he sends
S-EID, G over the top to S2. S2 has already built the three to S, so it knows that now
it has two external requesters because if one of them gets pruned you start to keep
that branch there. And then what happens is packets get forwarded down the first tree
from S to S2 through the locator ",G3" in the core to each of the trees down at the
bottom and that's how its works. So, what you use the locator set for in the mapping
entry is to send PIM join messages too. The way Unicast works is I send you a route you
return a Unicast data packet this way. But in multicast is I give you--you give me a
route, I give you a join, you return a multicast packet. So it's a three-step process, okay?
And then the packet comes to the edge. S2 then encapsulates it by putting its source
RLOC, the 11.0.0.1 on the outer header. It copies the inner G to the outer G, which we
know they're stayed in the core for that and then the routers in the core replicate the
packet to the sites where they need to go to, and then each of the sites will then replicate
to their internal trees, there is a left one and there is the right one. Any questions
on Multicast? That was the quickest multicast presentation I ever gave.
>> So, the replication in the pattern in the core that's the replication it has to happen
at the end? >> FARINACCI: No, the question was is the
replication happening in the core? If you look at that red arrow, that replication is
happening right here. And the reason it's happening right there is because both of the
guys joined into the same converging core router. If this guy over here decided that
the shortest path to S was through S1 then the replication would have happened in the
source site. It depends on which way Unicast routings converging you. If the two join came
in from a different path and converged into the site at S1 and S2, that's where the replication
happens. In fact, the replication would happen right here. If joined in this way and this
way, the replication would happen right there. >> JI: So now I have a question here.
>> FARINACCI: Yes, go ahead. >> JI: Yeah. Is this--just to make sure I
understand this. Is this any different from what--if there were just one receiver at each
legal Cloud and this was just ordinary PIM? >> FARINACCI: The question is, is this different
if there was one receiver at each Cloud just running PIM? It's...
>> JI: From the point of–-of the big cloud. >> FARINACCI: From–-so one packet gets sent
into the core since it's being encapsulated with 11.0.0.1 as its outer source address,
all the PIM routers in the core have state for 11.0.0.1, G because it only has Unicast
state for 11.0.0.1 and therefore the PIM, the PIM joins created the state based on that.
And so the replication happens on this locator ",G"
>> JI: Okay, okay. All right, I get it, I get it.
>> FARINACCI: Any other questions? >> JI: Well, to the extent that anyone gets
Multicast. >> FARINACCI: Yes, go ahead.
>> So none of those core routers have any knowledge [INDISTINCT].
>> FARINACCI: Yeah, that's a good point. The question was none of those core routers know
anything about LISP period let alone Multicast versus Unicast. And the answer is correct.
All they're doing is they're getting join messages in for an S, where S is not the Multicast
source. It's the ITR that's going to be encapsulating. So you're absolutely right, they can run without
any changes. Remember we said at the beginning of the presentation, we want no changes to
the core routers or site routers. We've been able to maintain it here by doing this. We're
encapsulating an IP Multicast packet in another IP Multicast packet, okay? Good observation.
Other questions? What do we do about MTU? There was a question about that. So, what
happens is we are putting additional header bytes on and we're going to make the packet
larger. So there's--the specification says that there's three ways of dealing with this.
We really don't care because there's enough MTU-sized links. And the MTU to access--MTU
is greater than the--or I should say the core MTU is always greater than the access MTU
so there's plenty of room for tunnel headers. Most of the infrastructure links are 44, 70
or 9K gigi. And 10 gigi are becoming more ubiquitous and more cheap. Hash its MTU list.
The only time there's a problem is you connect two large MTU things with a dumbbell through
a 100 megabit Ethernet and that's probably not going to happen. If it does happen, it
might be at the edges. And if that is a problem, we have two mechanisms, the Stateless Mechanism
and a Stateful. The Stateless Mechanism says if a packet comes to an encapsulator and it's
going to add these bytes, which is going to violate the MTU of the outgoing link that
it will first fragment the packet then encapsulate. So, the decapsulator decapsulates the fragments,
forwards the fragments to the host, and the host reassembles. Routers don't reassemble
packets very well and no hardware today. Any vendor can support that. So we want to avoid
reassembly in the decapsulator in the router, okay?
>> But it's important to note that when you say core, you really mean search router interior
and [INDISTINCT]? >> FARINACCI: Yeah, the question was when
I say core, I mean, service provider interior edge and what you mean is assuming that there
is enough MTU-sized links in those areas. Yeah.
>> STEVEN: In all of your examples when provider X and provider Y which [INDISTINCT] with each
other across some fabric light or packs, and the packs are a little bit smarter enough
to turn on jumbo frames and each of the provider--the question looks hard enough to set the MTU
on the interfaces so that on fragmented [INDISTINCT]. >> FARINACCI: Yes. So, the statement that
Steven made was if two service providers are, say, peering over packs, you have to assume
that they turn--packs turn on jumbo frames and that the routers are configured appropriately
to use those larger MTUs. And the answer is yes, we are looking forward, not backwards.
It's going to be more cost-effective to go to gigi and jumbo frames and more of the products
that vendors are shipping are defaulting to the larger MTUs. Now, will the host send packets
with large MTUs that varies on your host implementation and that could--as far as we can tell, most
hosts are sending packets with 1,500 bytes that leaves plenty of room. If they start
sending with 4470, then we can use number three to address your problem or the large
host problem where we wanted to avoid fragmentation at all cost and we use path MTU discovery
between the encapsulator and decapsulator. We keep the effective MTU state per map cache
entry. So, when we get packet do big messages to the encapsulator, we propagate it to the
host and we tell the host to lower the MTU. So, if there's a path going through 100 megabit
between the source and destination, that source has to send smaller packets. If it takes another
path through a larger one, that source or another source can send larger packets. So,
that's basically a Stateful solution. Did I address the question about MTU? When–-okay.
Other questions? What about locator liveness? Well, you can use the routing table when you
can if BGP is running on the encapsulator. And you know that you want to use a particular
locator and you have a route that matches the routing table, you can assume that the
destination is reachable. I mean, just because a BGP route is in the routing table, it doesn't
mean you're going to get the packet to the destination. All it means is that you think
if you send it to the next hop, it might be able to do the same thing. So you really don't
know that the locator is up. You might know if it's not there that it may be down. But
that's not clear either. Now, if the BGP routes there, it could be an aggregate where the
more specific that these destinies are going to match, it's going to be down somewhere
further down, right? So, you could just send and pray and see what happens. You could also
use ICMP. But ICMP doesn't tell you when a path is up. It only tells you when a path
is down. And how do you find out when a path is up? You got to try again. And if you try
again with data packets and you're wrong, you drop packets. This is bad, okay? Other
thing with ICMP is routers are starting to default it to not sending ICMPs. There's a
lot of filtering boxes that will filter ICMPs so you can't even depend on it. So the top
two, you can't even depend on. So we brought up--we built four algorithms in LISP that
happen in either the data-plane or the control-plane that is outside the mapping database that
will allow you to try some reachability. But as you find out that you get less scalable
as you go down, but you solve more cases, okay? The Locator-Status-Bits are bits that
are in the encapsulation header. And it allows a set of ITRs when they encapsulate data to
say, my two other brothers are up and they're running because I know I'm hearing from the
IGP that they're up and running. Those are hints saying that the boxes are up. But if
this site is trying to talk to one of them and that site is talking, "We have no idea
if the path is reachable or not." So this will tell you right away when something goes
down. But when you set the bits saying, "It's up," you don't know if the path is up. So
again, it's a hint. It doesn't handle all the situations. If you have bidirectional
flow between two locators then you can do this thing called Echo-Noncing. What we can
do is we can put a nonce in the data packet and I can request. If my ETR is Steven, I
can say, "Steven, please echo-back this nonce." And if he sends--encapsulates packets back
to me, he can repeat the nonce that I sent and that could tell me that I have a forward
path to him. I actually don't know if he has a forward path back to me because he could
have taken an asymmetric path back to me. But all I know is that he's echoing my packets
so he's seeing my--my packets he's decapsulating. But that only works when there's bidirectional
data between the two locators. What if there's not bidirectional--there's bidirectional data
between the two sites but the packet goes this way from this encapsulator to that decapsulator
and packets return from this encapsulator to that decapsulator. In that asymmetric case,
we can't use either one of these, okay? So we have this thing called TCP counts which
could be used, which basically does a depacket inspection from the encapsulator. The encapsulator
will look at a SYN packet going out. And if the SYN/ACK came back through another router,
and the host then send the ACK to the SYN/ACK through me again, since there's packets that
are coming this way I can count the X and count the SYNs. And if they're the same or
within the threshold, I know that there's bidirectional connectivity to the site and
that I could still keep using that locator. That assumes that TCP is used, that assumes
that TCP connections are going up and down so it's not totally reliable either. And now
you have per flow state. No, you do not have per flow state. We just count the total number
of SYNs and ACKs per locator per map cache. I did it with 2 32-bit counters and that's
it. No flow state. Flow state is bad. You know that. So the best solution and the worst
solution is RLOC-Probing. What we can do is we can send map request from an ITR encapsulator
to an ETR decapsulator. I can send a map request with a probe bit saying, "Just respond back
to me." I can measure RTT. I could find out--if it's up, I can use different locators. But
the problem is I have to send an RLOC-probe for every single locator of every single map
cache entry. That's where the ultimate scalability problem comes in. So what the implementations
do right now is have this all turned off by default and we send them praying say, "Hey,
the Internet is robust. It usually gets packets to the destination. I'm probably going to
be able to reach the locator on the other side. And if there's some failure in the middle,
we're going to trust rerouting a BGP in the middle to get the packet there. That's a good
place to start, you know, module of all the complexity." Now the other thing we could
do is we can turn on a combination of these that kind of work pretty well. We can turn
on RLOC-Probing and try to suppress the probes whenever we have an opportunity to suppress
them. That allows us to scale better. So, if Echo-Noncing is saying, "It's up," that
means I don't have to send probes to those guys, okay? If Echo-Noncing is not working
then I'm only using RLOC-probing for the asymmetric case. So we're doing a lot of experimentation
to see, should we use two out of the four or all of them and see what happens. Comments?
Yes, go ahead. >> [INDISTINCT] by worst than this, than the
standard IP routing because your masking the RLOCs behind the ETRs and therefore there's
more potential damage because you deliver it all the way to the endpoint and the [INDISTINCT]?
>> FARINACCI: Yes, that was a good observation. The observation was it's different than regular
IP routing is because the edges are doing it, where if you injected a PI prefix into
the core right where the failure point is, as you can do a reroute, and the guy just
keeps sending packets into this buffered pipe called the network. Yes, great observation.
The level of indirection buys you something but it cost you something as well. Scott,
did you have a question? >> SCOTT: Can you infer liveness from the
mapping [INDISTINCT]? >> FARINACCI: The question was can you infer
liveness from the mapping? I can tell you that I'm connected to Sprint and AT&T right
now but everybody who wants to send packets to me have a different path. And we don't
know unless they try it if it's up or down. So the answer is no, you can't infer it straight
from the mapping. >> Isn't it, [INDISTINCT].
>> FARINACCI: Yes, it's path for me and encapsulator to you another--a decapsulator and the packets
that I encapsulate to you is your locator and that's why we call it locator liveness,
ETR liveness, decapsulator liveness, it's all the same thing. Yes. Questions? Now, what's
nice about RLOC-Probing that I really like is that if I'm going to be probing with Map-Request,
if you decide to add a new locator to your mapping entry, the Map-Reply comes back and
I just get an update, because if I decided I want to send it every minute, I can get
mapping updates on minute granularity at the expense of probing.
>> [INDISTINCT]. >> FARINACCI: Yeah, how often are you going
to change? >> What prefix center are you [INDISTINCT]
by a distribution clause [INDISTINCT]. >> FARINACCI: Yeah. So, I think the comment
was is, yes, you can use this to update to your mapping but as you increase the number
of probes you have to send and you wanted to scale not use your bandwidth and all your
queues, you have to spread it over time. And spreading it over time means--my mapping updates
won't be as quickly as you--one would hope. You're absolutely right.
>> And does it--doesn't that mean that you have to be probing per RLOC and not per ETR
or just per ETR and just assume all of these? >> FARINACCI: That's one and the same thing.
The question was do you have to probe per RLOC or per ETR? Each ETR has a locator address
and you have probe each one. >> [INDISTINCT] multihomed ETR.
>> FARINACCI: A mult--if I'm an ITR in a multihomed ETR and I want to talk to your site that has
four locators, four decapsulators that I may use, I have to probe each one, if you want
to find the liveness for each one, right? >> What about when you talked about–-well,
the mapping whether that [INDISTINCT] so that I can recommend [INDISTINCT] skills on one
of those packets that are...? >> FARINACCI: Right. So the question is "When
are we going to talk about authenticating map replies so you can't inject a mapping
into the system and redirect traffic for a legitimate site to an illegitimate site?"
That'll be next week for sure. Okay. If you want to know more about any of those one specific
details, we have slide where--and we could show you some results. Is this something people
would like to more about next week? There's a lot of material for next...because the mapping
database infrastructure is important? If you don't want to wait, you can look at the LISP
working group presentation slides from Stockholm, which was summer of last year where we gave
a presentation on locator liveness and the problems with it and how you should not do
RLOC-Probing. And then we followed it up with the slide set on, you should need to do RLOC-Probing.
Okay, standardization status of LISP. Well, we started in--kind of, started in 2006. I
mean, arguably, Locator/ID split was done pretty early. We're going to give credits
to Noel Chiappa because he is the one who really made it part of a real architecture
called Nimrod, which was one of the IPng candidates did not--which did not occur. And so, we've
been working with Noel quite a bit. He's the kind of our conscious of this and he wants
to be able to build this overlay type system. So if we could actually have two consenting
sites implement something completely new like IPv10, it could run over our LISP infrastructure
because what runs in the core and what runs on the site can be completely different. Dave
Clark said that this is nice because it decouples the core protocols from the site protocols.
So, maybe this is something where we can move into the future and actually introduce new
routing architectures. We'll see. So most of 2007-2008, this work was done in the routing
research group of the IRTF, and that's where some of these specifications came out. The
second set of drafts or the database mapping algorithms. Some of that we believe will have
more of a success rate than other ones. I left one out actually. And--then we built
the interworking spec at the end of 2007. Last year, in 2008, we had two BOFs, a start
and a restart supposedly. And then in 2009, we have three working group. The plan is,
is by fall of this year to have these specifications that are listed on the bottom side other than
LISP mobile node to be experimental ROCs and close the working group. Okay. The Loc-Reach-Algorithms
as we've talked about in the last slide were done on mid-last year, implementation and
presentation to the ITF. Now, what's really important is everything is done in the open.
All the work has been done in the IRTF and IETF so that proves that it's open. Cisco
people have worked on and Cisco engineers have worked on it but we have no IPR on it
whatsoever. Our lawyers are going to stay off our back. It's an open effort. We're trying
to help the Internet. We're trying to scale it to a next generation and leave a good legacy.
So we've talked to other--we, specifically Cisco, have talked to other vendors like Juniper,
Arista, Huawei, XKL and we've talked to our researchers who are actually working, looking
on things like look up time, packet loss, different mapping database algorithms, how
to interwork, should the mapping system do caching like DNS, should it not. We've talking
to map--many service vendors--we'll talk about this more next week but. now that we have
this mapping service, we're going to have these MSPs, Mapping Service Providers, that
can be the vero signs of the world, the gold daddies of the world, ISC, Google, MSN, these
sort of guys could actually sell mapping services if they wish to. And they could sell it at
like the DNS hosting guys like it sold this as a monetized service low-cost, high-volume
sort of business. And who will actually put a proxy encapsulator, so non-LISP sites can
talk to LISP sites. We'll talk about interworking next week. One important thing to note at
this point is that people will always say when you build a new technology. He's like,
"Why should I be the first one to go to it?" and, "Will 50% need to be converted before
I get benefit?" That's not going to happen with LISP. If you're the very first LISP site,
you will get multi-homing benefits day one because all the numinous traffic will go to
infrastructure boxes. We believe service providers will want to deploy because they want to attract
traffic. And those proxy encapsulators will obey your policies and encapsulate to your
locators as you specify, and you can get active-active multihoming day one. So that's really important
point, we hope. And, of course, we've talked--CISCO has a huge customer-base. So we've talk to
customers that may want to do this inside an enterprise, that want to do datacenter,
used cases, mobile nodes sort of used cases. We'll talk about all those in a couple of
weeks. >> Questions.
>> Sure, go ahead. This is a good time. >> So, this actually does not address, so
to speak, the address exhaustion problem. >> FARINACCI: Right.
>> Which I think is a feature. I don't think it's a bug. I just want to make sure that
we're on the same page. >> FARINACCI: Yes, at the beginning of the
presentation I said--oh, so first of all the question was, is this trying to solve the
address exhaustion problem? The answer is no, but you may get more addresses based on
the solutions we're using but that's not our goal. I said at the beginning of the presentation
is that this is not keeping IPv4 alive, this is not keeping nets alive, this is not obsoleting
nets, this is not pushing you to IPv6. There are situations where this can make it easier
for two IPv6 hosts to talk to each other when they don't have connectivity to each other.
And we will talk about that in the used case as well. Yes, Scott.
>> SCOTT: So, I don't know about the [INDISTINCT] do you see that?
>> FARINACCI: Yes. >> SCOTT: Do you guys have any--I'm having
a hard time wrapping in my head on how to talk about or any, do you have [INDISTINCT]
fiber or was there something on that? >> FARINACCI: So the question is since these
EIDs are going to be in inner headers, how will these infrastructure components that
like to look at packets do it, do their thing, right?
>> SCOTT: How does a geolocation [INDISTINCT] or how does a geolocation DNS answers [INDISTINCT]
locators? >> FARINACCI: So the question was how is the--the
verbatim question was does geolocation work nice with LISP? And could you be specific
on what do you mean? >> SCOTT: So if I'm using Akamai service,
Akamai is going to pay me an ID based on DNS, based on the geolocation DNS...
>> FARINACCI: Yes. >> SCOTT: ...and they have correlation at
all to the RLOC, right? >> FARINACCI: Right, exactly. All referrals
will be done on EIDs. So anything that's done that's talking about host or referring things,
even if you want to refer to something that's a router device or a firewall device, it's
all based on EIDs. And then, the underlying routing system will map that to a locator
to get the packet to its current location. So we can actually build a GRE tunnel between
me and you. Me as Dino, you as Scott, those are IDs. And if that tunnel has to be re-homed
somewhere else, the underlying LISP infrastructure will say, "Now, the tunnel is going to endpoint
at Google because that's where Scottis." But now that he's in Starbucks, the tunnel will
just automatically go to a new place. So, all referrals are based on EIDs because we
want to still maintain the level of indirection. Okay? Question.
>> Okay. So, the ultimate [INDISTINCT] was the goal of [INDISTINCT] table sides and they
tried to reduce the table, to reduce the [INDISTINCT] to basically remedy and make [INDISTINCT]
but the cause of that that you [INDISTINCT] 1% [INDISTINCT]. So what was actually [INDISTINCT]...
>> FARINACCI: Yes, good question. The question was this, the original goal was to save routing
table space and therefore save memory space and possibly CPU and router boxes, and at
the expense of adding more overhead per packet. And the question is, is that a justifiable
cost to do it? And the answer is we, you know, the designs are made up of tradeoffs. We want
to be able to put the mapping database in an alternate infrastructure where there is
cheap memory and more plentiful CPU and more commodity prices. Okay. And we, by making--by
moving the problem somewhere else and adding bandwidth and header overhead to the solution
space, we think is a good tradeoff. There's lots of protocols today, not only at the network
layer, but at the application layer that put extra headers on and do tunneling in this
game. So we're not really introducing anything that's new or out of whack. The LISP encapsulation,
you know, if you're going to encapsulate an IPv6, it's a larger header. But there's 8
bytes of UDP and 8 bytes of LISP. You can do point arithmetic to get you to the inner
headers. So firewalls need to filter or do any policy based on EID. They can do that.
Yes, those devices will have to change to do that. But now, you can filter an identity
and your access LISP can be based on identity, and it doesn't matter where something has
moved because the EID will always be fixed. Okay. Any other question?
>> JI (PH): Can we get--one more question. >> FARINACCI: Go ahead.
>> JI: Are you hearing my voice. >> FARINACCI: Yes, we can hear you. Go ahead.
>> JI: Yeah, okay. So, in the first--and let's say that this gets--this starts getting deployed
and some large--some large firms sign up and get the listening routers, connect them through
providers through--sorry--not their own IP address space while they're providing--individual
providers they're connected to. >> FARINACCI: Wait, let me...
>> JI: You don't have to talk to the rest of...
>> FARINACCI: Wait, wait. Let me interrupt because--let me set the question up so you
can ask the question, and then I'll explain how this gets all set up from a site's point
of view and then it will make it clear to everybody. What happens is your site and--let's
say you're already have PI address--well, let's say you don't, okay? That's more important.
Let's say you want to go get a new PI address and you're in the--and you're in Amsterdam,
okay? What you do is you call up your IP and you say, "I want a provider independent address.
I never want to renumber again. That's my prerogative. I'm binding from you. The registries
will be happy because they're selling address space." So that will become the EID prefix
for that site. Then they'll go shopping around for service providers. They will get a single
IP address from each service provider, assign it to their PEC link on their CP router, and
that will be the binding, the EID prefix from the registry and the locator set from all
of the service provider IP addresses. And then, they will decide what the priorities
are for what policy they want to use. >> JI: No, no, no, right. That...
>> FARINACCI: That--well, let me finish. Let me finish because this kind of sets a good
stage for next week. Then what happens is those ETRs at the site will then register
those mappings to the mapping database system securely. And now that map request will flow
to that site, they will be able to get to this site and be authoritatively responded
to by those ETRs. That's how we would envision subscribing to the system or provisioning
the system. Go ahead with your question. >> JI: Okay. So, the question is about not
using the system. Until a fair fraction of the Internet or at least of consumer facing
ISPs and large corporations start doing things. >> FARINACCI: Why? Why? Why do you have to
wait? >> JI: Wait, wait, wait, let me finish the
question. So until this happens--let's say I won't bind to this when I get these boxes
and I deploy them. I still have to announce my provider independent address space so the
rest of the world can reach me. >> FARINACCI: That is not true. You have to
wait until next week to hear about interworking. If you want non-LISP sites to talk to you,
you do not have to inject a more specific route from the LISP site.
>> JI: Okay. I'll wait until next week. >> FARINACCI: Thank you. Any other questions?
>> [INDISTINCT] this time. >> Cisco seems to be pushing something called
Overlay Transport Virtualization which is the layer two held--it's an encapsulation
protocol. It seems to be designed to solve one of the problems that I think LISP is going
to solve. Has this train already left the station, or would LISP just place this? I
mean, what's the political situation? >> FARINACCI: That's a really good, insightful
question putting Cisco strategy together. No, no, no, you are not. It's just okay. So
the question was that there's this architecture called Overlay Transport Virtualization or
OTV for short... >> It is apparently available in the Nexus
today. >> FARINACCI: Yes, it's going to be available
in the beginning of April, I believe, in the Nexus product line. What it's trying to do
is to have a more general--a more general VPN strategy where you can do L3 or L2 VPNs
over an infrastructure. And the paradigm there is that you have these edge boxes that actually
run the IS-to-IS protocol at layer two advertising MAC addresses. So you can actually have routers
appear across this overlay infrastructure or build out to VPNs without having to do
MPLS at the sites. You do MPLS at the core, of course. But this is a many-to-may sort
of connectivity. It's not set of point-to-point pseudo-wires. And the reason it's there today
it's because protocols like the VMotion, VMwares, VMotion and Hyper-V and those sorts of things,
and other type of protocols assume that there's layer two connectivity that layer two adjacencies
are important because they send broadcast for discovery protocols, these link local
multicasts, they assume that the IP addresses don't change. Now, IP address doesn't have
to change if you cross subnets and that's where LISP comes in and that's where your
insightfulness came through. So we do believe LISP could help in this scenario but there
is a problem, and I'm going to explain this in the third week on a datacenter used case,
is that if a server is talking to a server or two VMs are talking to each other on the
same subnet and they move to a different cloud, that server still thinks it's directly connected
from an IP subnet point of view and still will send packets to the MAC address of that
VM, and if the MAC--if those packets can't be addressed to a LISP encapsulating router,
there's no way for LISP to solve that problem. So, we will show you in week three where LISP
is used, where's OTV is used, and where both have to be used at the same time, specifically
this later case. >> So OTV is going to make it to [INDISTINCT]
into this [INDISTINCT] resolving the layer two problem, for the layer two.
>> FARINACCI: Yes, I would say that LISP is going to make the OTV solution more robust
where just having VM communication among datacenters, if you have clients talking to VMs that are
moving, that's the case where LISP has to be used to complement the functionality. We...
>> [INDISTINCT] OTV because I don't like [INDISTINCT] datacenters together at layer two, you know.
>> FARINACCI: Right. So VMware is doing this thing called Long Distance VMotion and they
want to move something anywhere in the world which means across sub...
>> Stay the same. >> FARINACCI: Yeah. And LISP--we have this
solution called LISP VM, the VM mobility solution that will help solve this. So we'll talk about
that in two weeks in great depth. Yup. Any other questions? Steven?
>> STEVEN: Open flow. >> FARINACCI: Please comment on open flow.
I will do that when the tape stops rolling. I don't know. Are you asking the question
about open flow relative to this scope or... >> STEVEN: [INDISTINCT] they will show a video
[INDISTINCT] system of VM migrating--[INDISTINCT] migrating ground. Capability-wise, there seems
to be some parity there. Have you--I mean, have you looked at all at what they're doing
perhaps that you could prepare perhaps scalability, mobility?
>> FARINACCI: Well, we've--yeah, we definitely have looked at what they're doing but not
with respect to movement or Locator/ID Separation. I mean, there is lots of--there is lots of
solutions that can allow VMs to move. They all do it in different way. We want to solve
a certain set of problems of Locator/ID Separation and all these other used cases just to turn
out to come up and work pretty simply because the level of indirection helps. You know what,
every computer science problem can solve at a level of indirection. So--but we will--if
you think it's important, which we can certainly take a look at how they're doing movements.
So, we'll show you what the design goals for a very large mapping database system is and
we have four proposals, three of them that are kind of obsoleted or documented as probably
not good solutions, and the ALT is the one we'll go into detail with. That will be presented
next week in part two. >> [INDISTINCT]
>> FARINACCI: Right, exactly. Actually, the CONS proposal has two types of boxes. I think
I presented it in April of 2007, but CONS have Content Access Routers or CARs, the content
distribution router's approval. Okay, there are some old people there that are in the
audience. That's good. So those are basically built-in functions in the LISP programming
language if the young people care to know about that. Don't waste brain cycles on that
one. Then we will also show that the mapping database system is actually modular. You could
actually pull out ALT and maybe put in a DHT or some of your favorite mapping system. And
since the sites access the mapping database system through Map-Resolvers and Map-Servers,
we have this separation where we can plug, take one out, and put it in, and we don't
have to change the sites, we just have to change the Map-Servers and Map-Resolvers to
interface with the new system. So that's--that will be interesting so we can see over time
as people get experienced with this mapping database if this is the right tradeoffs that
we made or is the economic models or business models changing where we have to use a different
type of algorithm. Then we will definitely talk about interworking. Let me introduce
the concept of proxy-ITRs and proxy-ETRs, and that allows non-LISP sites to talk to
other sites. And we'll address JI's question about how do you do that without even injecting
a route from the site. And then security and tools that we have--we have--we believe we
have just enough security and not too much security to shoot this--to shoot ourselves
in the head and we like you to judge that when we present it next week. Part three;
we're going to put it all together. We'll demonstrate if we can. We'll show you the
live network. We can do some pings and some traceroutes and show you some mapping databases
if you'd like. We have a dual-stack mapping database infrastructure that runs both IPv4
and IPv6, so you can run IPv6 EIDs and IPv4 EIDs over either locator, and we're running
it across 10 countries. And we're modeling it as the top level or the different registries
and then they map out to mapping service providers and then there's proxy boxes that are at the
service providers drawing data and sending them to LISP sites. We're on our third generation
of the LISP network design. We started building it in the summer of 2007 and we're now--we
just cranked the third generation. We're getting a lot of good support from Asia, and we see
that growing out in time. Well, we can show the content and applications that run on this.
We'll validate and test economic and service models, that's the plan for the network. We're
learning so much from the network. We have real implementations running on it. We have
basically three implementations running on it. We have a XOS Cisco implementation, an
IOS Cisco implementation and a public domain implementation. We will talk about LISP mobile
node where Dave and some engineers are working on a LISP mobile node implementation on Android.
Thanks to Steven for giving us hardware. And we will talk that as part of the used-cases
as well. That's the third bullet there. We have four datacenter used-cases that we'll
talk about. And VM Mobility is the hot topic today but cloud sort of applications are also
interesting as well. And the multihoming is what you're pretty much heard about, but we
could talk more about pros and cons of that. Here's the Internet draft material, www.lisp4.net
is the external website. That is--it turns out to be a LISP site of University of Oregon.
Dave administers it. And you could connect to it now and it shows that you at Google
or non-LISP site, you can connect to it and open up a TCP connection. You will see that
the DNS name is a 153.16/16 prefix. That is a donated prefix that we use on this test
network as the EID prefix. We went to [INDISTINCT] and we have a 20.6.10.0, it's the 0/32m we
got from [INDISTINCT] to use it as the IPv6 EID prefix, so we can do either one. This
lisp4.cisco.com is actually an HTTP server at Cisco that has two ISRs in front of it
running the IRS implementation, and we're going to put content up on that to show you
that interworking in LISP of this stuff works as well. And I think that's it for today.
Questions? Comments? Tomatoes? I haven't seen Ed Crabbe in 15 years and you look just as
young as you also have, man. >> JI: Can I run this on my little home Linux
Residential Gateway that I put together? Not the one that I can buy from Linksys but the
one that I put together myself. >> FARINACCI: What was the question? Can you
run LISP on it? >> JI: At home I have a little Residential
Gateway that I built up on an old computer instead of buying one from Linksys because
I want to control what runs on it. Can I run LISP and build on it? It's running Linux.
>> FARINACCI: Yeah, you'll have to talk to the--so there's an effort called open LISP
that has done work on FreeBSD. Dave is working on a Linux implementation that will be part
of mobile-node--the mobile-node effort and the Linksys effort as well. But I think there
is some information on www.lisp4.net. Dave... >> JI: Okay.
>> FARINACCI: Yeah. >> DAVE: Yes. Okay, [INDISTINCT] will have
it sort of close site [INDISTINCT] part of it. It will be [INDISTINCT] so it will be
available for [INDISTINCT]. >> FARINACCI: So Dave says that'll be kind
of host type implementation of LISP on Linux and it could be available--it will be available
in the public domain to put on a Residential Gateway type box.
>> [INDISTINCT]. >> FARINACCI: And presumably patches our welcome.
Yeah, I presume so. Yeah. Yeah. >> DAVE: [INDISTINCT].
>> FARINACCI: Send over your patches. Okay. Thanks a lot and see you next week.
>> Thank you.