LISP Part 3 - Deployed Network and Use-Cases

>>
So one's again playing to a packed house, the man who needs no introduction, Dino.
>> FARINACCI: Apparently, I do. We need more people. Okay, welcome to part three. What
we're going to talk about is the Deployed LISP Network as well as apply a half a dozen
Use-Cases on how you can use it. So this will be pretty applicable to, you know, IT people,
people that want to deploy features, that sort of thing. So, we'll give you a summary
of the part one and part two, talk about the LISP Test Network. We'll describe some Network
Debugging Tools that we're using and then we'll talk about a Pro-Bono Use-Case, two-Enterprise
Use-Cases, a Service Provider Use-Case, three Data Center Use-Cases, and then conclude with
LISP Mobile Node. So summary of the first presentation we gave part one, we're talking
about routing table growth. You're not--yeah, you're not expected to read all this. This
is just here to say that these are some of the high point slides from the first part.
>> You know [INDISTINCT] regurgitation. >> FARINACCI: It's an, yes, okay, okay. So
I'm re-puking this, is what you're saying. Okay. So we talked about routing table growth
and how this can help, but we talk about how polluting the internet with more specific
routes and PI-prefixes is making the routing tables get larger and how LISP can help with
that. We talked about how you separate ID from location and the D mark point is where
the LISP of encapsulators and de-capped--decapsulators are. The level of indirection that LISP provides
you is that you can keep this EID addresses fixed while you are able to change the locators.
And so you don't have renumber sites, you don't have to renumber systems or virtual
machines and you just change the locators. And therefore we have this mapping between
an EID and a set of RLOCs which is part of the mapping database that we talked about
in part two. We gave an example of Unicast packet forwarding, and Multicast packet forwarding,
talked about how to solve the MTU issues associated with encapsulation, and then we talked about
locator liveness. How do you--when you decide you want to use the locator to encapsulate
too, how do you know if it's up and you should use it versus another locator in the locator
set? And then we talked about Standardization of LISP and an open policy where LISP is completely
open even though people from--engineers from CISCO are working on LISP. There's no CISCO
IPR on it. It's completely open. So when we show the Unicast packet example on part one,
we showed that the encapsulator had a cache entry and knew where to encapsulate too. Well
if the packet comes to that encapsulator and it doesn't have a map-cache entry, how does
it go get it? And so we described the Mapping Database System. And we described what the
scaling parameters and requirements were. We talked about some various algorithms. We
said that we decide to use something called ALT which is in the middle of this cloud here.
We talked about a mapping service interface by using Map Resolvers and Map Servers which
are boxes you add into the infrastructure. You don't have to change existing boxes to
realize the mapping database. Then we moved on to how to inter-work non-LISP sites with
LISP sites. And we talk about a NAT solution briefly. And we talked about these things
called Proxy ITRs and Proxy ETRs, or Proxy Encapsulators or Proxy De-Capsulators. We
put it all together in this one diagram down here where how it all fits together and how
we can change the mapping database if we need to without changing the sites. And we talked
a bit about security indicating the perfect is the enemy of the good. And so we have to
be careful that we don't have too much security mechanism and not realizing enough security
but just enough. Talked about LISP and Trace Route, how Trace Route gives you the entire
path regardless of it's an EID part of the segment or the locator part of the segment
and how we have a tool called LIG that queries the mapping database just like DIG would do
for the domain name system. Okay. So let's talk about the LISP. We called the LISP Pilot
Network, the LISP Test Network. It's quite real. We're doing a lot of experiments on
it. The point being is that we're trying to build it out, not get terribly large but just
enough so we show some kind of the internet structure on top of the existing internet.
We have about 60 boxes deployed now in 10 different countries. You can see the platforms
ranged from ISR, NEXUS 7K, C200, ASR 1K, those are the number of boxes per platform right
here. We're running the two operating systems at the moment. Later, we will add IOS XR as
we see fit. What we try to do is build--we called these boxes in these various regions
after the registry names. So we actually have this box sitting in Amsterdam. And there's
actually somebody at right that's actually running it and being part of our test. And
of course, we have a couple of boxes in Virginia. We have some--one in South America and Uruguay.
And the Apnic box is sitting in Sidney. And we're--there are Stub Sites sitting off and
these are the names of the sites that are connected. There are a lot of individuals.
Some companies, you'll see Facebook, MSN, Savvis is part of it, ICANN, those sorts of
people. These MS SPs are Map Service Providers and they're actually trying to model multiple
MS SPs at this level of ALT so they can aggregate up but yet provide options for somebody who
wants to purchase Mapping Services from different Mapping Service Providers. This is a blow
up of this region right here. We'll show you that in a little bit more detail. So what
we do is the two Arin Routers are dual-homed. The red addresses are locators, of course.
We--it's all dual stack. We show that this region here is MSP-1 which is basically most
of the West Coast sites connect to it and this is the MSP-2 where the East Coast sites
are connected to it. Right now, they're doing IBGP over GRE tunnels to each other. This
is all the Tunnel Topology because this is a control plane technology for sending map
request that's the sole purpose of this. You want to send a map request from the source
site to the destination you want to talk to, you want the ETRs or the decapsulators of
that site to give you the locators set so then you can encapsulate and send packets
to them underneath. So this is the hierarchy that we have. And you could see that these
Stub Sites will register to these Map Servers. These are Map Servers, Map Resolvers. And
they'll register. Then we call it /24 or /28 routing because they're getting prefixes out
of the EID space. And these guys are storing them. And when they go upbounds in the hierarchy
they allocate to /21s, and these guys allocate to /19s. So if I get something that's--if
I get a /24 from Arin because I'm in the US region and I want to use MSP-1 because they
have better service, I could use them. If I no longer satisfied with their service,
I can go to MSP-2 but still the same aggregation. Northbound is the same. It still aggregates
up. This--this has supposed to have a connection to the ALT directly. I don't know why that's
not there. I think it just a typo or something. So the idea here is that I could switch service
providers as a Stub Site and be able to go to either one if I want different service.
So this could be a VeriSign. This can be an Equinix. It could be a Google or MSN if they
want to provide mapping services. It could be an ISC or a DynDNS. Those sort of companies
could provide these services if they're going to be third-party. Service provider could
also provide these services and package it with their link cells that they sent to you.
You know, you could say if you buy a bandwidth from me, you can also get mapping services
for free or whatever, that's the idea. This region here are the actual--the proxy boxes
that'll actually provide non-LISP sites connectivity into the LISP world. And you could see we
have one at ISC University Oregon. Andrew Parton has one up and Equinix has one up as
well in Ashburn. >> [INDISTINCT]
>> FARINACCI: Yes. Yeah, the question was Andrew, this ASP-PITR box. It's a proxy ITR.
Yes. So he's actually taking packets and from non-LISP sites going to LISP sites. And the
LISP sites that want to return packets, we'll just send them natively if their service providers
don't uRPF-failed because the source address that's coming from the LISP sites will be
EIDs. And you have to make sure that they're--they don't uRPF. So the PXTRs mean that they support
both functions. Yes? >> [INDISTINCT]
>> FARINACCI: Sure. >> [INDISTINCT]
>> FARINACCI: So the question was, is there any freeBSD or Linux implementations running
in this network? It turns out there is we have a freeBSD implementation of LISP called
OpenLISP that's being done by Luigi and Damien. They're out of Germany and Belgium. And there--so
this is suppose to be used to support multiple implementations as well. So as more implementations
come up, I didn't add a slide about implementations but there are five distinct implementations
of LISP right now. And at the last IETF, we did a little interoperability thing. So there's
the OpenLISP implementation by Luigi, there's a Linux implementation by two ITFRs. There's
IOS, there's NX-OS and there's a click implementation that runs on Mac OS that'll get all those--right
Darrell? Okay. So the goals of the network is obviously to do experiments to learn about
if the protocols will actually work in practice rather than on paper. We are changing the
standard or the internet drafts as we learn things on the network. And we're trying to
not to get into the same problem we had over the last 20 years with BGP where BGP the spec
and BGP the implementation are completely different. We're trying to keep things in
sync so somebody who wants to implement LISP can actually look at the spec and it could
actually interoperate with previous implementations. We really want the multi-vendor part of this
to work quite well. So as we learn things from experiments, we want to adjust the protocol
in the architecture if necessary. We're trying to be careful about feature creep because
a lot of people want to jump in and say "Can you add this? Can you add that?" So we're
a little bit careful with that. We do want to test multiple implementations as I brought
up and we're starting to do that on that test network as well. We want to prove that this
ALT Topology maps --the EID allocation delegation maps to the Topology rather than the other
way around in using the /24 to /28 agreeing to /29 to /19 is suppose to emulate that sort
of behavior. And we're hoping that, that will be able to be enforced when a real Mapping
System gets put in place. And that we can control the back doors and, you know, the
triangle sort of thing though. The horizontal links need to be at the same level of aggregation,
and as you send advertisements up, you aggregate. And we're hoping we can do that. And since
the--since there are these boxes that are easy to deploy because there are separate
boxes that runs on PCs perhaps and have GRE tunnels. It's easy to re-home these things.
You don't have to provision links and, you know do all this layer 1 stuff. It's all over
the top type stuff. And of course, we want to emulate the MSP business models because
that's kind of new. We'd like to model it off of DNS-type services. It's just working
at the network layer rather than kind of the application layer. So we believe that people
will have a dependency or a contract with their EID-prefixes. They'll buy their EID-prefixes
from the registry. But they'll have a contract with a mapping service provider to get them
advertised. This is completely decoupled from the underlying connectivity that you have.
So you don't have to depend on the person or the organization that's giving you links--link
connectivity for the addresses. Therefore, you can change the service--mapping service
providers or change underlying service providers without having to change the other one. And
that--that's the decoupling that in the level of indirection that you get with LISP. Protocol
Learning Tool for users, we can--when people want to see the stuff live, we can log in
and say. "Look here's a trace route, this is how things work, it's a great learning
tool," to show it in action and show how real it is. So that's a big advantage to. And it's
a Test bed for building Management Tools to see if we need more tools to test LISP. This
is a web page which basically does a LIG to all the devices that are on the network that
basically tells you, you know, what site they're at, what box is being pulled, what their registration
is, what EID-prefixes they're registering, that sort of thing. And then we have somebody
that has built a LISPmon thing that basically tells you where all the LISP boxes are. And
you can click in and find out what their status is and just to do some, you know, network
management sort of things. Costumers, well, I shouldn't say costumers because I don't
think they're buying LISP yet. But these are people that are interested. These are people
that we've talked to the LISP group. These are either people that have received a LISP
presentation or around the network or proactively helping us design it. And you can see they're
from a kind of all walks of many different sectors. And, you know, a lot--I mean we went
to the financials like a few times. They're very interested just because they don't--IP
address management and moving virtual machines around is a big problem they want to solve.
Of course the Cloud Providers, I mean I should have put Google in there as well but they're
interested because they want to move Topologies quite a bit. And the Handset Vendors as well,
Google maybe should be in there as well so. So when people hear of LISP, what do they
actually say? What are the sort of comments when they hear the presentation and they see
the level of indirection, what are the sort of comment they say? And you know, they say
things like, "Oh, I want to--I would like my--to make my enterprise core network simpler,
and I can do that by removing routes. Having less turn, less flux in my core is a good
thing. So removing routes in my enterprise core, my datacenter core, or my internet core
even is a good thing." "I can allow my client machines to roam and I can track them since
EIDs never change." So that's kind of good where now the voice is associated with an
IP address which is called the MEID. And that EID never changes so it's always associated
with one system process virtual machine no matter where it's currently located. "I can
use either global or private addressing and I have to change them, I own my addresses
I have control." So yeah, you could actually build VPNs and duplicate your addressing because
as you--as it goes over the LISP, it's just encapsulation. And consenting sites can run
whatever they want. They can run IP version 10 if they want to, right? "I would like to
multi-home and use private addresses but it is so hard to do with NATs, I can do that
now with LISP." Multi-homing is very difficult with NAT. Multi-homing without NATs is difficult
because you have to run BGP at the sites. So we're going to make a simpler way of doing
multi-homing. "I think I can use LISP on my PE routers and use BGP next-hops as locators,
now my core can stay clean of external routes and I don't have to use MPLS." Okay, and right
now, you can get all your external BGP route outside of the core because from PE-to-PE's
MPLS labels. But now what you can do is you don't have to use MPLS and you can get your
external routes out of--out of the core and still have PE-to-PE, and you can actually
go from PE to a PE in another service provider because the tunnel encapsulation could go
across service provider boundaries where that's never done with MPLS. "If I can modify LISP
priority and weights, I can use LISP for load-balancing traffic to servers." Well, that's just dynamically
changing the priority and weights, and we believe that those two policy attributes the
priority value and the weight can be used and dynamically changed based on using the
traditional things you do in load-balancers to find out what's loaded and what's not.
"I can get IPv6 at my remote offices without upgrading my core." We talked about that last
week. You can run anything on the edges and you can use any kind of address as an EID
and what you encapsulate over is what is supporting the core. So you can run IPv10 or IPv6 over
IPv4, and it works because we're mapping one type of address of any format it could be
a MAC address, it could be a name to something that's runs in the core. "I care about leaving
a robust and scalable Internet when I retire. I want the Internet to be Green." Okay, that
was Dave Mayer. Okay, he wanted to leave--he wanted to leave a clean Internet to his grandchild--his
grandchild now will be grandchildren soon. But he basically wants to have the core clean
and scalable so we can keep the Internet cheap or there'll be something else that will be
the Internet that we have to might--we might worry about. So that kind of is a segway into
the Pro-Bono Use-Case is we would like people to pull their prefixes from the core. It's
either the Internet Core, the Enterprise Core, it doesn't matter. If there's less resources
been used in the core, we have a Greener Core. We use less resources, less memory, maybe
you can get devices that are cheaper, maybe router vendors could deliver things faster
because they're just not memory upgrades but they're feature upgrades, and of course you'll
use less power, and the core will be cheaper to operate. These are all good things. It'll
be Greener to deploy a PI-based IPv6. Most prefix allocations for IPv6 are going to be
PI. If we continue this, we're going to have a flat routing in the core, well, that actually
scale. So we can keep IPv6 EID-prefixes out of the core. And guess what? If we don't have
any IPv6 routers moving packets, we're going to have to keep those prefixes out of the
core, okay? So let's look at the first Low-Opex Multi-Homing Use-Case--Enterprise Use-Case.
So the Use-Case is basically multi-homing that we've been talking about. Multi-homing
is on the increase. People want more Bandwidth. The Internet is just as important as water.
It can't go down. You need multiple links for redundancy. So people are going to--they
may have multiple links to the same service provider, but there's a good chance that they'll
have multiple links to different service providers. And they want to do it active/ active. They
want to use both links so when one link goes down, they use 100% of the other link then,
and they want to use it quick. They want to switch over it quick. So we want a Low-Opex
switchover and we don't want to have this conditional advertisement stuff that we typically
run MBGP on S1 and S2. So we want it to be on Low-Opex. We want to use more efficient
bandwidth use for the site. All of the bandwidth is used for because you pay for it. The site
should be able to decide how it uses the link if it's 70-30, depending on the band--the
speeds of the link, or it should be 50-50. And there'll be new link revenue for an ISP's.
So an ISP should look this because this is more multi-homing and easier to multi-home.
They can attract more customers sooner, and so they'll--they'll be able to track more
link benefit at the benefit of keeping those sites routes out of their core so they can
sell new bandwidth and they don't have to pay for it in terms of routing tables entries
in their core. And we decouple the addressing from the ISP so the site has a flexibility
to change providers. This is really powerful. Now a lot of people say the service providers
aren't going to like that. Well if you want his customer and he's your competitor, it
is a good thing. Yes, you better keep good service because you don't want to lose your
customers. But the class can be a half-full. It raises the bars for ISP's. They're better
for consumer sites. Okay, question on this? You probably heard this in the previous parts.
The next Use-Case is dynamic and roaming VPN's. Okay, so we have this situation where you
have these five physical locations for, saying, a company that has five offices. And let's
say engineering is in San Francisco or New York and marketing is in Boston and Los Angeles
and you see that they're all multi-homed to the enterprise core. You see all the red addresses,
which mean their locators and you see the green addresses. I hope--I hope that's showing
up, but the green addresses are the EID's. And you'll see that--that the engineering
is using global PI addresses because it wants global connectivity. So they're using prefixes
out of 1.1.16 and 1.2.16, and you see that a mapping entry for this site would say, "This
1.2/16 has these two locators, 64.1.1 and 65" or "65.4.1.1.1 and 65.4.2.2." And you
know that the core is using global PA addresses, right? So we are able to keep those green
addresses out of the core, that's good. And let's see, marketing wants to use private
addresses. Well, they are addressing one class when anybody else is addressing because it's
all encapsulated in the core, it's just routing to red addresses. So we could actually use
192 addresses or any--any type of private addressing to talk to each other at networks.
Of course, the addressing has to be unique inside of the EID-prefix or you can make a
TCP connection to--we try to make a TCP connection to somebody else that has the same address
as you do. You're going to make it to yourself, right? Take that the packet out of the host.
But what we can also do is we can take this engineering site here in New York and we can
have it moved to Dallas and, of course, the prefix and all the routes and all the devices
just move here and then all that happens is the locators has changed. So this is a way
of a site actually moving, and then it's not just one machine but it's an entire topology
that can move. And by doing that, if you can move a site, you could dynamically create
a site as well because the site just comes on with a new EID-prefix with new locators.
It registers itself to the mapping database and that's how people find it. And you know,
when you have these server systems that are setting here, you go ahead and put--in DNS,
you put the name to address mapping out of the EID space. They never have to change.
If you move or stayed still or create something new, the addresses always stay the same. The
mapping--the DNS to address mapping always stays the same. Let's go to the service provider
Use-Case. Let's say a service provider wants to support multiple address families. Well
the Internet core is not dual-stack. We'd tried for the last 30 years; it's not going
to happen, so we have to figure out a way to deal with it now. I hope we don't have
to do translation because that's going to be very painful. I hope IPv4 host don't have
to talk to IPv6-only host. But let's just look at a few combinations. Well, like I said,
if you have an IPv6-only hosts--only site here, an IPv6-only in the running list on
both sides, it's really easy. This is an IPv4 path that encapsulates from this point to
this point. The inner header has--is an IPv6 header. The outer header is an IPv4 header,
okay? If that IPv6-only site wants to talk to a dual-stacks site, it's just running LISP.
This is LISP but that's non-LISP, it doesn't matter what protocol family it does. But obviously
it's going to encapsulate to a decapsulator, which is a proxy box and that path right there
is IPv4. It will then forward natively to this path which is on IPv6, okay? Oh, oops,
go back, okay? This case is a LISP site that's a dual-stack. That's also talking to this
dual-stack NAND. As you can see here, what we're showing you is that all this possible
combinations can work because we always encapsulate in what's homogeneous from this path to this
path and what's homogeneous to this path to that path. This is an example--this bottom
two clouds are an example of what I did with IPv6.google.com is that I have a LISP site
with IPv6 EID's connecting to Goggle which is an IPv6 site with routable IPv6 addresses.
And what I would do is encapsulate my packets to a proxy ETR. And the reason I do that is
because when my ITR here said, "I wanted to talk to this 2001 address," it wasn't in the
mapping database. So that tells me it's a negative cache entry that if I either try
to forward it natively or I encapsulate to a proxy decapsulator. The reason I want to
forward it natively because I don't have IPv6 path between these two points. So what I do
is I encapsulate it to a proxy box which decapsulated and has negative--it has IPv6 connectivity
to Google and then that goes directly. So this is a tunnel path and this is a native
path. This is--all the IPv4--all the purple here is a tunnel path and the yellow is a
native path. What if it's the other way around? This could be a possible cable company that
has an IPv6 core. You can't upgrade the residential sites because they're running set-top boxes
with IPv4 and the truck rolls are just too expensive for them to convert all the residential
sites to--to IPv6. So what do they do? Well, if this is made today, an IPv4-only site,
residential, running private addresses, if I'm running LISP, I can encapsulate the IPv4
packet in IPv6 because that's the only thing that the core network supports. And then it
gets decapsulated by an IPv4-only site that has a server using a global address, okay?
Likewise, if I'm a LISP site that wants to talk to a non-LISP site, of course, this address
here is a globally routable address. So I encapsulate my IPv4 packet over IPv6 to the
proxy ETR and decapsulates it and forwards it natively on this path, which is probably
going to be a few hops through the head end to the data center or whatever. Questions
on service provider Use-Cases or enterprise use cases? Let's go to the data center.
>> [INDISTINCT] one second? >> FARINACCI: Go ahead.
>> [INDISTINCT] other... >> FARINACCI: Oh, okay.
>> So let's go to the--what are you showing here is like, you know [INDISTINCT]
>> FARINACCI: Yes. >> [INDISTINCT]
>> FARINACCI: So, the question was a lot of examples we showed are showing multi-homing
with a couple of dual-home basically, but what if you, let's say, we have hundreds of
connections that go outside, how would you use LISP to give you the level of indirection
because you're going to have a hundred locators basically. So what we're--so the real limit
here is most of the protocols designed to deal with 32 locators per EID prefix because
we have bit field in the datacenter that's advertising locator status bits. But what
it means is that you get 32 locators for a given EID prefix of any length you decide.
And if you have a hundred type connection points, you're probably going to regionalize
the EID prefix and you get 32 times each one of those or 32 per each one of those. Yeah,
it's a pretty hard limit. You don't have to use the locator status bits, you can use probing
between the ITR and ETR to find reachability. So you don't even have--you could turn that
L bit to locate the status bit off from the data packets and not have to use them at all
and therefore the map reply then just gets larger. We can fragment and reassemble it
because it's a control protocol. So you could actually run it with more, but if you want
all of the feature that I've been all talking... It won't let it, I mean, a map request that's
sent, a map reply comes back. If you can receive an 9k MTU size map reply then life is good,
if not it gets broken up into multiple. So it's "1xnRRT" or whatever, you know, that's
all. Let's talk about data-center. The first Use-Case is going to be virtual machine mobility.
This is an example where these two boxes are first top routers "A and A'". They're layer
three boxes. They're running LISP and they're directly connected to these four servers;
S1 through S4, okay? Let's just say, I know I'm wasting address space big time here but
let's just say these are on point-to-point lengths and that these are the addresses of
each of the servers. Well, it turns out that all these ports that are off of the cell three
box can register and aggregate, say, the /16 to the mapping database saying that the locator
is A which means me. Anything that's going to go to any of these servers, please encapsulate
the packets to me. These two boxes are just a legacy IP router. So they could be, you
know, CAT6Ks, Juniper boxes, it doesn't matter, okay? Same thing over here, this guy registers
the 2.2/16 with "A' as it." So what we're going to show now is what if S1 moves or virtual
machine on S1 that comes out of that address 1.1.1. moves to S3, what happens? Well, "A'"
can tell when this guy sources packets that it's not coming from this subnet, and when
it's not coming from that subnet, that triggers the mobility of that, saying, "Somebody just
moved on to my subnet." And so what I'm going to do now is I'm going to register the host
route saying that the locator is me, "A'", no longer this guy. This is--right here is
a route that goes--this is a mapping that goes into the mapping system not the underlying
network. It doesn't even get advertised throughout the alt either so it's actually going back
to the same Map-Server that's covering 1.0.1/32. I will show you that more detail when we talk
about LISP Mobile Node, which has a much harder scaling problem to solve than virtual machines.
So that's the fundamental idea. Now, what happen is there's one sending packets out
now in this new path. It has updated the cachers. The new guys that want to talk to will go
to the mapping database and get "A'" as the locator versus A as the locator, but existing
cachers have this A, so you update them and, say, you solicited--we call them SMR, Solicit-Map-Request
to the cachers so that they can update their cashes and now encapsulate to "A'". That's,
basically, how we will get VM mobility to occur and notice across subnets. You don't
need a layer 2 domain anymore to be able to get VMotion to work or Hyper-V or whatever.
Questions? Yeah. Go ahead. >> [INDISTINCT].
>> FARINACCI: Yes. >> [INDISTINCT], is there something like you
will turn this something to all the... >> FARINACCI: Oh, yes. OK, so--that's a good
question. The question is there's an update here and do you have to flood it to all the
people that might care about it? And the answer is no, there's no flooding. It's not--we don't
classify it as a mapping update because the /16 is a completely different mapping entry
in the database than the /32. So look at it as we're adding this new entry to the table
and it turns out to be a longer prefix, so when people want to send to 1.1/ 32 they use
"A'", anybody else in 1.1 that use A is encapsulation. Now, the only--the only site--the only place
that has to carry the /23 is the Map-Server 4.1.1/16. That's the only one he has to store
and the current ITR's that are encapsulating to you. Those things are done dynamically,
and they are done dynamically by saying, "If I'm going to send packets to the guy, it's
only active flows that are going to be updated and the guys have gone silent." Even though
there's somebody that has a map cache entry pointing to A, if they're silent and not sending
data, we won't update them. So everything in LISP was pretty much [INDISTINCT] and we
try to do it fast when we think we need it. >> So, [INDISTINCT]? So how do they know like,
you know that--this is my concern--they no longer [INDISTINCT].
>> FARINACCI: The reason the cachers know that the 1.1/32 is no longer is associated
with A is that when data packets start flowing Egress from "A'". It knows who he's talking
to so he knows who the locators are for those destinations. And what he does is he tells
them that send the map request to me and then there's an RTT time where he gets updated.
The... >> If you can take--the questions were about
live flow. >> FARINACCI: Yes, that's what I'm talking
about this live, folks. >> So a live flow is not talking to the cache.
The live already knew. >> FARINACCI: The live flow is talking to
somebody on the other side that's LISP-aware either it's the L3 box that's talking that's--there's
an ITR on the other side or a proxy ITR. That thing has to get updated to know--to send
packets back that comes the "A'". And we do that with this thing called an SMR. Let me
give you an example. So 1.1.1/32 is sitting there on S3, it sends a packet to some things
called 10.1.1.1. This guy may already have a cache entry for it but if it doesn't, it
sends a map request, okay? That map request will go to the site that has 10. Now, don't
forget that site that has 10 does have a map cache entry for us but has the wrong locator.
That's what we're trying to fix, right? So what happen is that map request gets sent
over to the 10-site, and what's in the map request is actually this guy's new mapping.
So he has it piggybacked in the map request. The guy can--that guy at 10 can actually just
cache it if he wants to do it on another system or he actually can verify it by sending a
map request back with the same NANDs and then the map reply happens. So what I do is I send
the map request to you but I set this bit that says, "I'm soliciting a map request from
you. I want you to ask me what my mapping is." And you're going to send it with a NANDs,
a 64-bit NANDs, then I'm going to send the map replay back. And then I'm going to give
you this new information. It takes three-halves RTT to do that, but you don't have to do it.
It could take a half RTT. If I'd just say, "Here's the SMR, but it is a Map-Request packet."
And the source--this information is in it, you can believe it if you want. And we see
in a datacenter that that's probably going to be trusted because it's managed by all
one, you know, administrative control. Go ahead.
>> [INDISTINCT] >> FARINACCI: Right.
>> [INDISTINCT] >> FARINACCI: Right. If there's no--so you're
saying, if most of the traffic is unidirectional coming from the remote site here, you know
he's going to be sending to the old place. What can he do? Well, one thing that "A" can
do is he could first tell the mapping system that he's no longer the locator, and he could
find out by doing a database mapping lookup that he finds in the new locator. He could
just go--he could query the mapping database to find out where he moved to. He's not going
to be able to do anything until it lands. When it lands, it gets registered. Only after
at that point he can find out. And when he finds out, he can either proxy map reply or
he can actually tunnel the packets. We don't propose him to tunnel the packets horizontally
because we don't want the ---, okay. So there's all kinds of options those are all various
options we can do. But, you know, when you're running something like VMware, they give us
so much warning that they're going move, we're going to be already to go, and the guys around
in TCP and they're doing heartbeats before they do--before they say, "Okay, now, let's
do real data." The network state will be all created by that in point in time. You should
ask that question again when we bring up mobile node because that's where it's harder, much
harder. Yes, go ahead. >> [INDISTINCT]
>> FARINACCI: This one? Yeah. >> Yeah. [INDISTINCT]
>> FARINACCI: Seven. >> One.
>> FARINACCI: Oh. Oh. >> [INDISTINCT]
>> FARINACCI: So I think the question is if somebody has 1.1/16 cached, and now they want
to send packets to the 1.1.1/32. What will cause them to send a map request, because
they'll just map--they'll have a map cached heads and won't...
>> [INDISTINCT] >> FARINACCI: Yeah.
>> [INDISTINCT] >> FARINACCI: Yes. That map request will go
to the mapping system that will return--that will...
>> [INDISTINCT] >> FARINACCI: This guy just returned /32.
He doesn't have to return the 1.1/16. >> [INDISTINCT]
>> FARINACCI: Yeah. >> [INDISTINCT]
>> FARINACCI: Yes. >> [INDISTINCT]
>> FARINACCI: Yes, correct. >> [INDISTINCT]
>> FARINACCI: The... >> [INDISTINCT]
>> FARINACCI: Right. So I think I understand the question now. You're saying should the
old guy "A" return back the mapping 1.1/16, add all the more specifics, because the guy
who is doing the request may want to talk to the move machine. And we want them to use
locator "A'" and not "A". >> Right.
>> FARINACCI: That's the question, right? Yeah. So in the multi-homing case, we call
this nested prefix. It's the multi-homing case you have to return all the more specifics.
In this case you may not have to because this guy's always going to talk to--if somebody's
going to initiate a SIM packet in a completely new place and he doesn't have it cached, he's
okay. If somebody already has 1.1.1/16 cache because he's talking to "S2", now all of a
sudden he wants to start talking to "S1". The ITR says, "Oh, I know where "S1" is it
matches the /16s at "A". But really "S1" has moved, right. That's the case. So that's exactly
like what I thought you set up first, then you said no, but it is the same case, okay.
It is the same case. So what you have to do is this "A" has to know that, I mean, in this
case we want "A" to return 1.1/16 and this guy to return just /32. If this guy is--if
there's anybody new that's talking, yes, he will go to the old place and will actually
degrade to the same cases what this gentleman said what the problem is. He has to know--he
has to know that "111" has moved and will know because he keeps staying there knowing
that "111" has move, and he'll either do a mapping database lookup to tell that guy to
"A'" or he'll re-encapsulate the packets and go that way. It's the exact same case. So,
yeah, I mean, what's hard about this handoff problem is not only do you have to know where
the new place, the new locator is. You'll also have to know that the guy is no longer
at the old place and you have to make sure that the state is kind of in the same phase,
we're out of phase, right? And the problem with multiple mobility problems is, especially
with mobile phones is that the VM that's moving may not be at the old place or the new place
yet, even when the network is trying to set it up, saying words going to go. And everybody
says what do you do when it's off the air? Well, you can't communicate when it's off
the air. There's nothing you can do here, right? So either you drop packets. If you
start encapsulating here before you rise, you're dropping packets here. If it gets here
and you start sending packets at the old place, you're dropping packets there. So what's the
clean switch-over? What we're trying to do here in these boxes is not dependent on any
signaling from the host. We're trying to solve it all in the network so it's transparent
to the host. But if the host can give us a signal that, "I'm leaving now. Don't tell
anybody about anything until I land." And then when you land you do it, then life works
pretty good. And there's--I mean, like, right now, VMware is an example. We'll send a reverse
arg and announcement is here. And that's when this mapping registration and updating the
caches can work. VMware could actually tell us the flows that it's talking to. And we
can say, "I'll do a database mapping lookup for all the current flows that it's talking
to." And then if I see some that are in the same /24, I'll send one request, get the prefix
back in the map reply, scan all the flows and say, "Oh, these three map did the same
prefix." So you can actually do some clever scaling things where you don't have to send
Nmap request or Nflows because they may aggregate to the same region of the network, which is
typically the case moving from one datacenter to the other because of the prefixes are much
more controlled than on the Internet. Yes. >> [INDISTINCT]
>> FARINACCI: Yes. Same will happen here. And this is the example, you have a machine
at your house that's talking to this IP address and there's somebody, either at your house
there's an ITR or there's a proxy ITR, that's encapsulating to its current locator. When
that VM moves you are still sending packets to the same IP address because it's IED, and
the ITR will find out its new locator and now encapsulated there. That's an example
over the Internet. >> [INDISTINCT]
>> FARINACCI: The mapping service is there because when new people want to talk to the
VM where ITRs don't have a cache, they have to lookup and find the locator, just like
they would have found it when it was sitting in its home area. If you've been talking to
the VM, it's a changeable locator in this case, and you're cache will be updated by
this guy because this guy has a TCP connection with you at your house. And we know packets
are going to be sent back to Steven's house. And what that means is his ITR needs to be
updated to find out the new locator, and that's what we do with this SMR exchange, send map
request. >> [INDISTINCT]
>> FARINACCI: The moves. >> [INDISTINCT]
>> FARINACCI: Yes, but you'll see how we can make it scale. That's the sugar at the end
of the presentation. Okay. So you--okay, you guys are really interested in this slide,
that's very telling, good. Go ahead. >> When does--you're suppose to bring from
gateway [INDISTINCT], so how did this actually move, you know, that it moves, so instead, okay, we even deliver
the packets that--you can deliver the packets that how they move, you know, I said in [INDISTINCT]
that also move as something here, who said there's [INDISTINCT] when [INDISTINCT].
>> FARINACCI: Yeah. The "A" could ping the IP address and find out if it's there, it
could probe. There's all kinds of implementation techniques. It can look at date of activity
and decide that it's been quiet and therefore maybe had moved. If it's quiet, you could
actually check the database and say, "Let me look up 1111." If it looks up "111", you
get the /16 back. It means it didn't move because it didn't get registered a new place.
Oh, wait, wait. Let me finish. There's a lot of more--there's more to it. Now, the other
thing is the host could actually send packets and say, "I'm moving." And, you know, Hyper
V and VMware and Zen and the red hot one, KVM, they all have their ways of signaling
to the network that we could use. And those are all implementation techniques that we
can enhance the convergence of the move. Okay? So we don't--but we don't want to have to
depend it on the day one because we see we could do without signaling from the host.
Okay? So, we know "A" will know when it moves. Okay? And if it's getting packets, it has
to make a decision to say that some policy decision is do I hairpin or start sending.
So, I get things encapsulated back, decapsulate, re-encapsulate them some of there so they
could be delivered. That's just like mobile IP, right? It's the triangle routing problems.
We could do that as well. We don't want to because we want to be better than mobile IP.
We want point to point tunnels because I want this stretch between you and me to be one.
I want to stretch between the clients at Steven's house to the VM to be stretch equals one.
It's encapsulating from his ITR and be then encapsulated by "A'" which is an ETR.
>> [INDISTINCT] >> FARINACCI: Yes. IPv6 mobile IT does that
eventually. Yeah. Yeah. But you need IPv6 forwarding in the core. That's minor detail.
Let's go to the next Use-Case--data-center Use-Case. So, we need 40 gig and 100 gig yesterday.
Everybody's been telling vendors that. >> [INDISTINCT]
>> FARINACCI: Yeah. I may be asking the same question. And so, most--with the way people
are dealing with upstream bandwidth today is they get 160 gig by 10 times 16 where 16
is usually what the A6 support on the number of ECMP pass. While if you had a little diameter
to the network and you put LISP in here, you can get 256 pass wide. So what we're showing
here is that this is an encapsulator, a LISP ITR. These packets come in. These packets--these
packets will match the one of 16 different locators that you encapsulate to. Those will
be looked up into the FIB. Each one of those locators will match a FIB route that maps
to 16 different next-hops. And if you do that with hash meeting in a 256 wide going to the
same 16 different ETRs that decapsulate and then delivered to the destination. Okay? So
256 wide because we got 60 times 60 because of the level of indirection. Questions? You
don't want to put in more routers. Is that what's Scott is thinking.
>> [INDISTINCT] >> FARINACCI: Huh?
>> While you're receiving the hash [INDISTINCT]. >> FARINACCI: Yeah. Yeah. Right. Okay. Okay.
You don't want that random number in there, right. Yes. Yes. So, here's the final Use-Case
for the datacenters is load balancing the load balancers. So what people are have--problems
that they're having today is that packets are being addressed to VIPs and these servers
are all being used up, but the VIPs aren't giving enough spread because of the way packets
are coming in. So, what you can do is you can treat the Virtual IP addresses which are
the IP addresses of the load balancers as EIDs. And when packets come in to these ITRs,
they can decide which ETR that decapsulates it and then we can spread the load across
this load balancers. So each locator maps to a set of load balancers that have the same
VIP and then they can load balance here. So it's hierarchical load balancing that can
be used. The final Use-Case. What if two mobile handsets could roam and keep a TCP connection
established? What if two mobile handsets LISP encapsulated to each other and have a path
stretch of one that they didn't have to go through a home agent? The home agent is a
data playing path where packets that returned to the mobile node have to go through the
home site because its address is topologically from their home site. Well now that we have
a locator ID separation, the ID can roam anywhere and the location is done part of the separation
and doesn't have to be topologically restricted. So we always have stretch of one for all LISP
encapsulation. What if we can put up server functionality on a mobile handset? Oh, you
can certainly do that now because www.abc.com always maps to the ones with the same EID.
When it moves, you don't have to change that entry. You don't need dynamic DNS. Static
is sometimes good, especially if it never changes. What if your handset could use all
radios at the same time? Is this a good thing? Is this a bad thing? So we're going to say
this thing or an Android is a sing LISP site. It's going to have any ID prefix. It could
be IPv for IPv6, but this is a prefix that's burned into the SIM perhaps. And it's going
to be configured with the Map Server that you know is aggregating. This is a Map Server
that you're buying service from. That's topologically aggregating this EID prefix in to the ALT.
Here are the two locators. One for each of the radios. And this guy now could say if
he wants active-active on these two interfaces, or active-backup. It's just like a multi-home
LISP site. So how do we do this? Well, we can run a very lightweight variant of LISP
on the mobile node. It just does basic encapsulation, really simple, much simpler than what an ITR
does. Okay. And that's documented in the Internet draft there. EIDs burned into a SIM card.
It can be either IPv4, IPv6 address that never changes. That will be your network name. This
is a cell phone number portability brought to IP. We're doing IP number portability now.
Okay. It will be yours forever. That's your network name. Your--now when you land--if
you go out of signal and you come back in to a WiFi, WiMAX, 3G, 4G, whatever, you will
get a DHCP address, that is your locator because you're tapping into the topology of the network.
So you have your binding. There's the EID, there's the locator. And if you're getting
a DHCP LISPs from both all your interfaces, that's your locator set that you register
with the EID. Now, the mobile node carries along the Map Server because it always wants
to register to the place in the ALT topology that's going to aggregate for you because
we don't want host routes to be in the ALT. It's not in the underlying network, but we
also want it on the ALT. Okay? So when you get a new DHCP address, you register your
Outlooks at the Map Server and you update the cachers just like we talked about in the
mobile--in the virtual machine case. Okay? Can this scale? Well, we leave RLOCs alone,
we mapped the underlying physical topology, that's why the DHCP LISP has told us where
we are and that routing is already routing to that sub-matter whatever. So there's absolutely
no more specific routes in the core for the LISP mobile nodes or any other LISP site for
that matter. The more specific state is only in the Map Server. The Map Server has to track
the /32 because the site that's advertising that EID prefixes is pointing to locators
at the home site not where the LISP mobile node is moved. Okay? So the Map Servers kind
of like a home agent, but it's a home agent in the control plane not the data plane. That's
what makes it different than mobile IP. The Map Server already has covering routes so
no more specifics are injected into the ALT, very important. We will keep that all pristine
as long as we can. Okay? The only other place for the more specific state has to be put
is in the people that are currently talking to you, the cachers. And that was the point
that you guys are homing out. So, how bad can that be? Let's have a look, back in the
envelope calculation, what if we--a map-cache entry, say, in our implementation a map-cache
entry caused you a thousand bytes of memory? Okay, violet means its memory cost, red means
its RLOC cost and green means tracking EIDs in map-cache entries. That's the scaling parameters
we have for this calculation. What if we said, we wanted to support one million entries in
an ITR that would cost you one gigabyte. Okay that's not terribly a large amount of money--memory.
So let's look at a Google ITR, a lot of cell phones coming up, they're roaming all over
the place and they're doing searches. So the ITRs at Google will have to support a gigabyte
in their ITR. And that means that single ITR could talk to only a million cell phones.
Let's keep scaling up. Let's deploy a 100 Google ITRs. Now we're up to 100 million mobile
nodes. That's not too bad. Let's throw more memory at it just by a factor of 10 and now
we're up to a billion mobile phones. A billion mobile phones in a 100 Google devices, it's
going to turn out to be that way anyways. A 100 ITRs is not unreasonable since good
user experience forces sure as exit. So we know that those ITRs are going to be regionalized
anyways. So, an ITR doesn't have to support a 100 million or one billion. It only has
to support one or 10 billion, and then we just cluster or we array it out this way to
get to a total of a 101 billion cell phones. Oh, by the way, 1000 bytes per entry is fairly
fat. We can optimize that, maybe not by an order of magnitude but maybe by two or three
acts. So, we just add it some more factor to it that can help. This is probably achievable
since granular state is only kept where it is needed. Comments from you guys, what's
your reaction? >> So,[INDISTINCT]
>> FARINACCI: So the question was, is this dependent on the full TTL, the map-cache entry
of 24 hours? No, shorter. >> [INDISTINCT]
>> FARINACCI: Yeah, but the churn in map requesting... >> [INDISTINCT]
>> FARINACCI: As the minimum TTL for the entry, is that what you are asking? So, we think
it should be--okay, it depends on a lot of things and there's tradeoffs all over. It
depends on how fast do you want to roam and if we could--we think, we could do that mini
granularity. But it turns out when a mobile phone moves, it could maybe clear its cache.
And when it clears its cache, it sends map request and then tell places where it's currently
talking to, at the application layer what the new stuff is. Just like the SMR example
that I used here. >> So for example, [INDISTINCT]
>> FARINACCI: Okay, wait, wait, wait, before we go to that, when you go home and you haven't
connected that in yet people can still get to your web server at your mobile phone at
home, first and foremost. >> [INDISTINCT]
>> FARINACCI: Okay. >> [INDISTINCT]
>> FARINACCI: Right. >> [INDISTINCT]
>> FARINACCI: So, you--so what you would do in that case is that the EID would move to
the physical server at home. The... >> [INDISTINCT]
>> FARINACCI: Yeah. Well, yeah, because... >> [INDISTINCT]
>> FARINACCI: Yeah, well I'm... >> [INDISTINCT]
>> FARINACCI: The EID is associ... >> [INDISTINCT]
>> FARINACCI: Oh, okay, so you want the EID to be mobile. What we're saying is...
>> [INDISTINCT] >> FARINACCI: Right.
>> [INDISTINCT] >> FARINACCI: So you want the www.scott.com
to actually go to a different physical server but you didn't say if the address should be
the same or not. Is the EID the same or not? Or you're asking, lets...
>> [INDISTINCT] >> FARINACCI: Right.
>> [INDISTINCT] >> FARINACCI: That'd be at the DNS name. Yeah,
yeah, yeah, right. So that's kind of outside the scope of what we're doing. Because we're
doing it--the key into the database is the EID, and anything that happens above it happens
independently from it. Go ahead, Darryl. >> [INDISTINCT]
>> FARINACCI: So that's a quick fix. >> [INDISTINCT]
>> FARINACCI: Right. >> [INDISTINCT]
>> FARINACCI: Right. Let me repeat that, so the people on the video can hear. Is that--so,
Darryl said, the best way to do that is make your TTL lower for the DNS name and higher
for the map-cache, so you keep re-requesting for a new DNS name. And if you get the same
EID or different one, either one could roam independently of that, but this is just connecting
to a different physical server at that granularity. >> [INDISTINCT]
>> FARINACCI: Sure. >> [INDISTINCT]
>> FARINACCI: Right. >> [INDISTINCT]
>> FARINACCI: Yeah. Yeah, yeah, good point. >> [INDISTINCT]
>> FARINACCI: Well, yeah. I mean, that's exactly the immobility case but the only difference
here is the LISP functionality is on the mobile node. And you're moving the server functionality
into a host, that's not running LISP but the XTR does running at your site is the new locator.
So what could happen is just by changing the locator when the new locator decapsulates
and finds out where this new EID is, it can now send it to completely different machine
because of layer two. >> [INDISTINCT]
>> FARINACCI: It certainly could, just like the "A" and "A'" example, where we said it
re-encapsulate to the new place. Yeah. >> [INDISTINCT]
>> FARINACCI: I mean... >> [INDISTINCT]
>> FARINACCI: But it wouldn't work that way, it worked the opposite way because everybody
still sending to mobile node. It would have to tell you to, now starts sending packets
to the mobile node or to the stationary node, right?
>> [INDISTINCT] >> FARINACCI: That sure is.
>> [INDISTINCT] >> FARINACCI: Yes.
>> [INDISTINCT] >> FARINACCI: Right.
>> [INDISTINCT] >> FARINACCI: Right. Okay, so I think that's,
I mean, we should go think about what a scalable way of doing that, but the node to take, Darryl,
here is that--they want EIDs to actually move on different physical devices because it's
more of a service address than a physical address.
>> [INDISTINCT] >> FARINACCI: Ah, okay.
>> [INDISTINCT] >> FARINACCI: Oh, yes. I'm just saying it's
a NAND problem but... >> [INDISTINCT]
>> FARINACCI: But it's the mobility yet at another level, right.
>> Right. I mean, I just want to [INDISTINCT] >> FARINACCI: Yeah.
>> With the interaction [INDISTINCT] >> FARINACCI: Yeah, yeah.
>> All right. >> [INDISTINCT]
>> FARINACCI: Do it--Darryl is saying, do it at the DNS level, because that's where
the level of--indirection now is at, yeah. Well, I could argue that, maybe another--I
could argue that you could use any cache addressing and make both systems the same IPv4 32 bits
and you can use an instance ID which is pre-pended to tell you, is it an instance ID that's a
higher or part of that address. It's actually the mobile phone versus the stationary phone,
and that could be used as a lookup into the database mapping to find out really where
the place to go. But that's just another level indirection that happens inside of the EID
space. So that, I mean, there is some interesting things we could think about there. Do you
think this could be popular, Scott; this feature of moving server functionality from one device
to the other. >> [INDISTINCT] the Use-Case I imagined is
that you have, you know, some--you know, some service that is associated in getting your
attention. And when I'm on about [INDISTINCT] phone vibrates [INDISTINCT] when I get home,
all right, I set phone down, I plug it in, I walk into another room, and so I want...
>> FARINACCI: And you want it on--you want the notifications to be on your home devices
now. >> There's a different means of getting my
attention when I'm at home that generally involves [INDISTINCT].
>> FARINACCI: Right. >> Or perhaps [INDISTINCT].
>> FARINACCI: Or more things not ringing. Yes.
>> Or, you know [INDISTINCT] into something [INDISTINCT] automation system [INDISTINCT].
>> FARINACCI: Right, right. Okay, cool, very cool. So this is following the last slide.
Just want to let you know that we've run this idea over the last three years through people
that have gone through these sort of evolutionary technology attempts. We did talk to Vint.
We had a--Dave Meyer put together an economic workshop. I think its have been about two
years ago. And Vint came and we gave a presentation. He liked LISP more for the mobility reason
than anything else. Dave Clark liked LISP because he said, "Oh, now I can build IP version
20 between these consenting adult sites, and we can encapsulate an IPv4 locators and we
can build this new--we can build new Internet because we could do whatever we want. And
I think I've talked about this a little bit with Steven and VJ at times. Noel kind of
works with us on a daily basis. He kind of--I'm going to give him credit as the Locator/ID
Separation Visionary because he talked about this 15 years ago and was part of his NIMROD
architecture. That was a candidate for IPng where SIP was the winner of the IPng wars,
and it became IPv6. Paul Mackapetris--if Dave was here, he would coin the phrase that Paul
said that the LISP works in theory or LISP works in practice but not in theory, and I
thought that was a complement actually. So he is going through the same--he went through
the same struggles that we are about dynamic updates. And he said, "We're not going to
do dynamic updates to DNS." And he went 15 to 20 years without dynamic updates until
that was added later. So he could understand that that's going to be the hardest part of
the design to get working scaling, and you guys have already brought that up. We went
up to Seattle to talk to Len Bosack, founder of CISCO, and said, "Len, what do you think
of all this?" He goes, "Oh, it's boring. It's just another encapsulation." And I said, "Thank
you. That's what I wanted to hear." So that's it. Here's the references, that's pretty much
all I have. I'm willing to take questions. Which Use-Cases do you think are compelling?
Or throughout the ones that you think are not compelling that I brought up?
>> So a lot [INDISTINCT] you think that, you know, that's [INDISTINCT] were the most compelling?
You know, the TCP and [INDISTINCT], you know, [INDISTINCT].
>> FARINACCI: Yeah, I think the Mobile Node Case will really help guide IPv6 to play as
well because if you really want global addresses in your mobile phone and you want two mobiles
phones that are on--with stretch one and keep the TCP connection up. There are no solutions
today that can do that. And, you know, Mobile IPv6 can't do that. Mobile IP has the stretch
of greater than one because of the home agent. So I think that this part what LISP brings
to the table is new and more efficient way of moving packets. We really have to make
the implementation light-weights, the Mobile Node Implementation lightweight, and that's
the key. And that's why, you know, thanks to Steve, and he gave us half a dozen Android
phones and we're doing an implementation now. And we're going to find out in the coming
months if we can make it really simple. The difficult part is it's part of the IP layer,
it's inside the IP, so it has to be put into the kernel. I mean, this is going to be hard
to do on an iPhone because we can't do it in user space, right? So that's why we're
playing with Androids since it's opened. >> The mobile case, the alternative that seems
is [INDISTINCT]. >> FARINACCI: Right.
>> And [INDISTINCT] that makes [INDISTINCT] that includes port number space and turn it
that into something [INDISTINCT] by people [INDISTINCT] and to distinguish.
>> FARINACCI: Yup, I agree 100%. >> Do you think in you're datacenter Use-Cases
number one, the--that really points out the need to, you know, if you're serious about
[INDISTINCT] the stable presence on the Internet, you know, that's been able to work. You have
to--you have to control your own maps server [INDISTINCT]...
>> FARINACCI: You have to control your own maps server. You, the site that has EID addresses
should control your own Map Servers. Is that what you're saying?
>> Yeah. >> FARINACCI: Okay.
>> Because there are, you know, we all know the function of [INDISTINCT]...
>> FARINACCI: Right. >> And there's no, you know, if someone, you
know, if someone can promise an [INDISTINCT], but, you know, if there are [INDISTINCT] Map
Services unlocks [INDISTINCT] because of, you know, I think that's, you know--some site
in the Internet that, you know, for which they have [INDISTINCT] service, some will
deploys this, you know, VM portability service inside, there's [INDISTINCT].
>> FARINACCI: Right, right, of /32s. >> [INDISTINCT]
>> FARINACCI: Yeah. >> [INDISTINCT]
>> FARINACCI: Thanks. >> [INDISTINCT]
>> FARINACCI: Right. >> There's no--there are no penalties that
can really [INDISTINCT]. >> FARINACCI: To no abuse that, right.
>> [INDISTINCT] >> FARINACCI: Yeah, I would argue that the
sites that want to control advertisements and would run their ALT PGP connections into
their ETRs. And if you wanted to support mobile nodes that the Map Server run on those boxes,
but they're only to support the prefix that you're injecting into it. And that's an example
I think that you're, you know. Yeah, because we just don't want any /32 to show up anywhere
because it doesn't work well for scalability but it may have all these policy and security
issues that you have to worry about as well. So, yeah, hopefully a Map Server dressed as
program in the phone cannot be changed by the at all that it has to be somewhat hard
coded or it's like a serial number, you know, it's factory installed. You can't change your
IMEI address exact--or number right exactly. So, it's something like that. Yes, yes, I
don't know if that's a feature of bug, but, you know.
>> [INDISTINCT] >> FARINACCI: Right, power users. Yeah. So
that's it. Thanks for coming guys. I hope you enjoyed the three-part series. We had
some continuity with a few people, so I appreciate the people that came, all three of them. Hope
you got something out of it and we look forward to working with you. Your input is really
appreciated. Thanks.