Noel Chiappa

Transcription

>> 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.