Monday 8th November Agenda Bashing Presentation and Note well 7 presentations scheduled: Status updates and issues for WG drafts draft-ietf-lisp draft-ietf-lisp-interworking draft-ietf-lisp-ms draft-ietf-lisp-map-versioning Individual submissions draft-schudel-lisp-mib-00 draft-farinacci-lisp-lcaf draft-jakab-lisp-deployment No issues rose concerning the agenda. Darrel Lewis presenting: draft-ietf-lisp ---------------------------------------- --> Darrel Lewis: I assume there is a pending review we have not seen yet. --> Joel Halpern: There is a security review that has to come in. --> Darrel Lewis: Any comments? If we can address the big issues we can go to last call after Prague. --> Joel Halpern: If we can do it before Prague would be even better. --> Darrel Lewis: So, if you have big area of concerns please bring them up on the mailing list. --> Terry Manderson: Just to reiterate Darrel's question, are there any questions/comments regarding the main document? Is anyone looking for further high-level work on that document? --> Joel Halpern: We do need to go through the tracker and make sure that all of the issues have been addressed. I think that there are some where you guys quite reasonably have sent some questions back to the comment originators and we have not heard back, we need to poke them more. --> Darrel Lewis: Do you want to poke them or you want to stop? --> Joel Halpern: You should send me a summary of the issues and then Terry and I will poke them. --> Darrel Lewis: OK. --> Joel Halpern: Thank you --> Joel Halpern: What's next on the agenda? --> Terry Manderson: Interworking. --> Darrel Lewis: No updates at this time. --> Joel Halpern: There are some issues on that related to the deployment but we will discuss them during under the deployment talk. Vince Fuller presenting: draft-ietf-lisp-ms ------------------------------------------- --> Joel Halpern: The working group has to review this change of the Map-Notify message. --> Vince Fuller: The message has not yet been defined. It is something we want to define and we came to the working group to seek for consensus on whether or not it is a good idea. If there are no objections we will go on and define it. We will then publish the changes and they will be reviewed and either approved or changed. Again, the purpose of this is to acknowledge Map-Register and is a mechanism for also improving the way Map-Versioning works, to keep the information consistent between ITRs, ETRs, and Map-Servers. The format will be the same as a Map-Register, using a SHA1 encryption with shared key between the ITR and the Map-Server. --> Vince Fuller: The other comment I wanted to make concerning the ALT spec is that there have been no changes to it and no comments since the last version has been published in April. We will issue a new version the keep the draft alive and update the references but we believe that that draft is ready for the last call. --> Terry Manderson: There was a question from Vince directed to the working group to say whether the Map-Notify is a good idea. I would like to hear any objection now otherwise we will take it to the list. --> Dave Meyer: Lots of implementations what they do is they send a Map-Request for themselves, as soon as they register, to try to get this information. This is a pretty onerous way to try to do a pretty simple functionality that this would provide for us. --> Dino Farinacci: The other case we saw in implementations was if the system comes up and does not have an ARP entry for the next hop the Map-Register gets dropped on the floor so it obviously take three minutes. Luigi Iannone presenting: draft-ietf-lisp-map-versioning -------------------------------------------------------- --> Joel Halpern: The question of the last point, whether or not add text describing how LISP and non-LISP sites talk in the case of versioning, is more about how much the working group wants to cover. I think we have to have some text that says how this works in the case of PITRs and PETRs. The question is whether you can get by with just a bit of text or whether we need a lot. --> Luigi Iannone: Exactly. Right now we have just a bit of text and we are not sure if the current content is sufficient or not. But we are ready to add text. Gregg Schudel presenting: draft-schudel-lisp-mib ---------------------------------------------- --> Greg Schudel: about draft status: we think MIB are useful and we're proposing to have it adopted as WG document. --> Terry Manderson: Since there has been a request to include this as working group document, can I have a hum from the group. If you want to have a MIB please hum. (Hum shows rough consensus on accepting the MIB draft) --> Terry Manderson: Ok, we will go for a MIB and we will take it on the list. Dino Farinacci presenting: draft-farinacci-lisp-lcaf ----------------------------------------------------- --> Dino Farinacci: Before starting, just a quick update on the lisp-multicast draft: there are no changes. It is a similar status like ALT. --> Dino Farinacci: Questions? Comments? Tomatoes? :) --> Dino Farinacci: There was some confusion, let me clarify. When I was talking about the AFI in the Instance ID part, I said 2+4 and 2+16 and that's a correct and intentional statement. The 2 and the 4 refer to the length of each of those fields. The AFI type field is always 2 bytes, so when is AFI equals 1, the length is always 2+4 and when the AFI equals 2 the length is always 2+16. Lorand Jakab presenting: draft-jakab-lisp-deployment ----------------------------------------------------- --> Joel Halpern: Your document says Map-Resolvers should be provided by the ISPs. I believe there was a lot of discussion on the list and it is not at all clear to me. I think we need a lot more discussion on that question because I can't get my head around that. --> Darrel Lewis: What I have tried to articulate in Hiroshima was that what we found while working on the pilot network is that by default there is no state requirement between the ITR and the Map-Resolver. We think that Map-Resolvers, like DNS caching resolvers are eligible to anycasting. We also found that you want to go to the nearest Map-Resolver if you can, because you want to go out into the ALT and you want to find the ETR as fast as possible. That is a little bit different than the relationship between an ETR and a Map-Server, where there is a security relationship between the two. So it doesn't really lend itself to anycasting and it doesn't really lend itself to the concept of just find the closest one. That's the kernel of the idea of having the mapping system as near to the ITR as feasible and have a strict relationship between the ETR and the Map-Server. So I think in the document, the very first wording was "provided by the ISP", but I think that's an oversimplification we have to work on. --> Joel Halpern: That's make more sense. I think there is a good question about whether anycast is the right answer, because of other issues of anycasting, but it is one we want to consider. For anycast or some set of providers that you know how to find, you want to find them easily, you want to have them nearby, but since the ISP are not particularly tied to LISP at all, there is no particular expectation for a site that goes to LISP that their ISP is going to be a LISP supporter. There is no coupling between those, so that's why I have a little problem on that. Speaking personally not as a chair, trying to understand where we are pushing. --> Lorand Jakab: After the comments on the mailing list we added to the document that at the very least there should be fallback provided somehow by the registrar, or somebody working with the registrar and that gets money for it. --> Joel Halpern: We need to spell this out better. --> Lorand Jakab: OK. --> Dino Farinacci: I think what you are saying is that people that should deploy PITRs should be types of providers that have a lot of data plane capacity and the registrars traditionally don't, so that's why you think it's not a good idea. --> Joel Halpern: I presume it's more than that; there are sort of two issues, I think. One is: it's a data handling function that better be provided by somebody who's a data handler function and that's what you just said. --> Dino Farinacci: Yes. --> Joel Halpern: The other is: it's a function that has a lot of demand on it and better be somebody who's got some incentives to do it. These are the two sides I see here. --> Darrel Lewis: I would add a third thing: it's better if the PITR is somewhere along the path that the packet was going to take anyway. It reduces the stretch so users on either end of the conversation are happier, but it also reduces costs to backhaul those bits. --> Joel Halpern: Absolutely. --> Lorand Jakab: That was another disadvantage I was pointing out. So far path stretch is much greater than usually because there is a few deployed PITRs. --> Dino Farinacci (referring to scenario in slide 6): This is untrue. We are talking about PITRs, which are encapsulators, so they are always sending traffic away from where receiving it from the costumer side. These priorities are usually put in ETRs, so are you saying that these two boxes are also ETRs for the site? --> Lorand Jakab: Yes. --> Joel Halpern: This is not clear. If the ETR for the site is also a PITR for the site then there is no LISP. --> Lorand Jakab: Exactly. --> Joel Halpern: I do not understand how this is a solution to consider. --> Dino Farinacci: There is a lot of confusion here. If there is ETRs, it's for the site and it's not a PITR, it's an ITR for the EID-Prefix of the costumer side. That's what are you trying to say? --> Lorand Jakab: Yes. --> Dino Farinacci: We need to clarify this in the document. --> Darrel Lewis: In the Interworking document this idea is kind of introduced. The basic idea here is that if I convert to LISP, if I still announce my EIDs in the underlying BGP core, I have the concept of routable EIDs. So non-LISP sites use the routing system to get to me and LISP sites use the mapping system and therefore the LISP encapsulation to get to me. What I want to say along the line is there is an advantage for a site to move along routable EIDs path, in the sense that for instance they can have a /24 out of their /16 that they want to try to use LISP with. So they do not withdraw the /16 and they do not announce the more specific, using BGP the way they did yesterday and they put the /24 in the mapping system. As a transition mechanism that might be ok. The downside of this is that if we just start to turn LISP on and all sites still keep announcing everything in the BGP then we are not better of as when we started. I do not think is a viable end state but it may be a way to help encourage people to turn on LISP for a portion of their infrastructure. The final thing I want to say is that I think there is another aspect of a site running a PITR. If they are not running LISP, in the sense they are not decapsulating packets, they do not have an ETR, they can put PITRs at their site so that when they talk to other LISP sites those LISP sites get the benefits of LISP. I think this description is modeled but it can be improved. I am trying to introduce the idea of where PITRs can belong at the sites. --> Joel Halpern: Those two I understand. I was having trouble mapping either of those with what I have heard. --> Lorand Jakab: Basically what I started to discuss is that it does not make sense to have PITRs and ETRs in the same place. I wasn't explaining it well. That is why the name is LISP+BGP because basically you have LISP for communications with other LISP sites and you have BGP for the rest. So you basically just turn LISP on and it is not exactly like the PITR scenario but is a transition scenario. --> Joel Halpern: I am missing some assumptions here. I can understand the idea that a CDN whose customers are using LISP might want to run PITRs for them, except that I don't see any aggregation. I cannot build in my head any model where I can expect that the set of customers for a given even large CDN actually have adjacent EIDs that I can aggregate. So if I want to advertise only a short prefix into DFZ so that the PITR does not blow everything up and so that we have some benefits out of this, then the CDN is suddenly handling traffic for a whole bunch of other people who aren't their customers. Now, get paid to handle traffic, that I agree, but they also aren't interested in handling traffic of folks that aren't paying them. --> Dino Farinacci: I just want to make clear one thing about benefit. Because everybody is talking here about a single benefit, which is routing table size reduction. If you deploy LISP you have ingress multi-homing. --> Joel Halpern: We are talking about benefits for PITR deployment not the benefits for LISP. --> Dino Farinacci: You said we are losing benefit; I want to know what benefit you are saying we are losing. Routing table size reduction is what your point was. What I am saying is that if you loose that benefit there are other benefits as well. I just want to keep that clear. --> Joel Halpern: The point of PITR deployment is to get the routing table size small otherwise we just use routable EIDs and we wouldn't need PITRs. --> Dino Farinacci: This is not the point of PITRs. The point of PITRs is to have non-LISP sites talk to LISP sites. The benefit of LISP is to get ingress multi-homing traffic engineering and to slow the growth of the routing table. Can we reduce the size? We can try, but there are problems that you just described that make it hard. But we should keep trying. --> Joel Halpern: Maybe I am missing something but when the PITR was first put forward the idea was that the PITR would be advertising very large portions of the EID space. I can't see how that PITR deployment model is consistent with PITRs deployed by CDNs. I am not arguing whether CDNs might want to support LISP. This is a different question from PITR deployment question. That's what I am trying to focus on. --> Darrel Lewis: About the route announcements expected to be generated by PITRs. There are three axes to this. The first is the scope of those announcements. If a site is using a PITR just to be a good neighbor of other LISP sites. Let's say I am a CDN, I do not really run LISP for my stuff but I just want to make sure that LISP sites get a good service for my content. So I run a PITR facing inwards, take the whole routes, dump them in my local routing table limiting the scope to my network. --> Joel Halpern: This model I can understand. --> Darrel Lewis: The second one is: what if I have a PITR that is announcing routes with no limit to the scope except for the economic model, like from a Tier-1. I am going to send them to all my customers and peers. So I send the announcements out to my large network and my peers and my customers. So the question is what all those routes look like? The answer to that has nothing to do whether it is a PITR or not. The answer is how fragmented is the LISP mapping system? Is the ALT a bunch of fragmented routes or is the ALT able to be aggregated at all? That's a LISP question not a PITR question. --> Joel Halpern: I disagree. --> Darrel Lewis: Two points. The first is that there is an opportunity for a PITR to proxy-aggregate your announcements. Thus any two EIDs that are adjacent part of two blocks you can aggregate on behalf of those two EIDs, because just getting the packet to you and then you follow the mapping system policies to get to the RLOCs. The second thing is that if you limit the scope you can aggregate further. There is nothing saying that if I am an ISP and I am going to have this PITR announcement and I am just limited to my ASN I can't just put a /4 in there and use it as a sinkhole. The stuff that comes in and is LISP, I encapsulate it. So there is that possibility and I think that we are going to try to explore that with the deployment document. --> Joel Halpern: I realized while listening to you that I have got to answer that with two different hats. Speaking as chair I have to point out that we were chartered to address the routing scaling problem, so when we talk about this PITRs deployments and any other deployment we have to make sure that we talk about how to address the routing scaling problem, because when I will talk to the routing area I am going to talk about that. That is what our charter is talking about. Now as a technical contributor, the issue I am confused about is that in order to interworking we need to have somebody deploying PITRs with advertisements of Internet scope so that the guys out there get service. --> Darrel Lewis: The interworking document describes NAT and PITRs. --> Joel Halpern: Unless we mandate LISP-NAT, LISP deployers are going to count on the existence of PITRs with network wide scope. That is the deployment assumption we have been making. If we want to change that we have to write it down and say that it should be different, we should tell everybody about LISP-NAT. I hope we do not want to do that and I think you guys agree with me. The CDN pointing at its own customers I understand that picture and we need to be clear in the deployment document which way we point. I think it is good and in scope, doing it for your own ASN has applicability, doing it for your customers has applicability, but we have to make sure we address the other problems. --> Darrel Lewis: CDN may be a poor choice of an acronym here. I think what is interesting about this is that other types of networks out there that have large multi-data centers in every corner have a low stretch to major portion of the Internet because of this large number of data centers. Maybe as a CDN they are not offering LISP but maybe they are also LISP registrars or mapping service providers, so apart of the other services they are providing, they offer as well LISP mapping services and interworking. My take on this is that CDN is a bad example because they do other things as you mentioned but a large global PITR provider may be not an impossible thing to vision. --> Joel Halpern: If there is any question/comment from people in the room, please speak now on the mic. --> John Scudder: About PITR aggregation, may be you want to consider what is going on in the SIDR working group in terms of who is actually able to advertise this stuff. Because you may build this PITR but if your origin AS doesn't look right may be nobody will listen to your announcement. --> Joel Halpern: Securing this is a different issue and we'll make sure the interaction with security works. That's why we want the security analysis. --> Joel Halpern: There is no reason to expect that LISP customers of an ISPs' EID to aggregate. The topologies are the whole point of the game. We have two separate topologies. --> Dino Farinacci: You really want to have the PITR to be close to the source sites that are not LISP. So I agree with Joel on this. --> Joel Halpern: I understand the idea of taking care of the non-LISP customers of this ISP. But what I am worried about is the customers elsewhere on the net. I am trying to figure out who is going to provide the PITRs for them. --> Darrel Lewis: Our current thought is that the mapping service providers would potentially provide this as PITR resource and originate those EIDs. Joel it does not matter if you think that this is not a good business model if we can find somebody to do it then this is all it matters. --> Joel Halpern: Yes, the question is not whether or not I want to get into that business. The question is whether or not it is a possible business model, whether the incentives are sufficient to make people believe this is deployable that way, because if the registrars have to deploy the PITRs and have to handle an unlimited amount of traffic for that customers. This is not tight to how big the customer is because it is only tight to EID allocation. --> Darrel Lewis: Why couldn't they go for that? --> Joel Halpern: If they are billing for that this is a different game. --> Darrel Lewis: What am saying is that if the PITR provider has a business relationship with the ETR, then why it couldn't charge for PITR service? --> Joel Halpern: That's a different model from what has been proposed. That's the model I would like to see written up. --> Darrel Lewis: It is not possible to write business models in IETF's documents. --> Joel Halpern: I understand. It is perfectly possible to write it up as a business relationship rather then an included service. That we can say. The problem I had was that this is an included service, that was just part of the service. As a separate service, we can understand it and discuss it. --> Danny McPherson: I think that we just need a protocol mechanism for this, because there are people looking at this. --> Joel Halpern: The problem that I have is that in order for this to address its problem space, it has to have a viable transition strategy. It has to work when a small number of people are using LISP and a large number aren't, but traffic is going between them and it makes use of LISP. We all agreed on that before: it has to be enough about the deployment of things like PITRs, since they are necessary components of that. Am sorry, Deployment and transition are necessary part of this; business model is not, I agree with you. Unfortunately it is hard to tear them apart. I love to be able to say we do not need to know who is going to deploy these PITRs but I tell you from discussions with other peoples, we can't just ignore that question. --> Dino Farinacci: So regarding the IPv6 allocation, I made the suggestion on the mailing list and only for IPv6 and I would like to request the working group to request IANA for a /16 or even a code-point in the /8 space. --> Joel Halpern: Anybody wants to comment on that? This is something we really need hearing from the working group. --> Luigi Iannone: I agree with Dino. In my opinion, this will simplify and clean out the deployment in IPv6, giving us some space to do tests and go on. --> Dino Farinacci: So regarding IPv4, the PI EID migration I think is pretty trivial because you just take the PI address that you have today and you put it in the mapping database system. They might not have power to do aggregation but there is nothing we can do about that. We have to figure out some automatic ways of taking ALT routes and advertising them by PITRs. But all the stuff you have talked about are ways we can do that as long as we can scope the advertisements of the EIDs, we should be OK (which means you advertise them like your last diagram said). --> Gregory Cauchie: Speaking as a provider, I think if we want to consider any deployment for LISP we have to focus on all these points. (referring to the last slide) --> Lorand Jakab: What do you mean all these points? --> Gregory Cauchie: All what you propose here. We can speak about the protocol and it is very important but then how, where, when, what are the impacts, pros and cons, etc. These are things really important to discuss about so I would be interested in seeing all these things addressed. --> Joel Halpern: Just to remind that mobility is out of the scope for the working group. We are not going to work on mobility in that document. --> Jari Arkko: I also want to say that there are things on this slide that are interesting and we should talk about them. And I have a question about this IPv6 prefix stuff. Size? How would that compare to other space in experimental work that we have done before in the IETF? I remember we have ORCHIDS, even if I forgot what the size of that prefix was. --> Joel Halpern: I think that a /16 is a reasonable thing to have. --> Jari Arkko: yes, a /8 is you know pretty big thing. When do we need this prefix? --> Dino Farinacci: Now. We have enough space. This will simplify a lot of things. --> Jari Arkko: If you have some allocation now and a bigger allocation, let's say a /8, later? --> Dino Farinacci: So what I also suggested was to have a code point in the higher order bits so when you see an IPv6 address today you know if it is a unicast or multicast. What I want to know if whether it is unicast, multicast, or a multicast from an EID, or an unicast EID because I wanna hardcode it because it makes mapping database lookups we do not need to do anymore for non-LISP sites. I know that is harder. --> Joel Halpern: There is not justification for getting a high order code point. If we need two code points one for unicast EIDs and one for multicast EIDs we pick a size that reflects the space the EIDs are going to need in the long run. We do not have to compromise on that but this will still be more then 8 bits. But that's ok. You can hardcode a /16 or /24. --> Dino Farinacci: If we are going to do the prefix allocation then the earlier the better. --> Joel Halpern: I have no problem in asking for a prefix for this. --> Dino Farinacci: I am just worried that like back in the multicast days we allocated just all types of different multicast addresses and then we had all these long ACLs that had to be configured and were misconfigured, and caused a lot of headache in multicast so I want to be well known. --> Jari Arkko: Getting a prefix of some sort like we did for ORCHIDS is a no brainer. The shorter it is the harder it is. --> Joel Halpern: We're not gonna get /8. --> Darrel Lewis: If we do not want to require the vast installed base of IPv6 sites to renumber to go to LISP then the EID for v6 will have a limited usefulness. --> Dino Farinacci: If we use the 2001 prefix we will have PITR scaling problem for IPv6. So let's be smart and avoid that. --> Jari Arkko: I want to understand your issue about the code point selection. --> Dino Farinacci: Give me a /16 and I'll be happy. --> Jari Arkko: I think this is probably doable but what I want to understand is if you hardcode something in your software do you have to recognize the allocation and then everything else that is kind of PI in IPv6 now? --> Dino Farinacci: Let me explain. Today when a packet comes to an ITR does database mapping lookup on this IP address and it has no idea whether the IP address is of a LISP site or a non-LISP site. For IPv4 it could be either. You have to ask the mapping database system and if the mapping database system gives you a negative Map-Reply back then you known to natively forward the packet because it is destined to a non-LISP system. Now if we had a well known code-point for IPv6 and a packet came to an ITR and we said "ah this is a well known prefix" then we know the mapping database lookup will be resolved in a set of locators, whereas if it is not we just natively forward it at that point. So sites that have not converted yet get the same performance they do today and they do not worse in performance by having a mapping database lookup and having a negative Map-Reply coming back and then you decide to send the packet natively. --> Jari Arkko: So if we are in that prefix then we know what to do, but if we are not in that prefix in that case we still have to check from the mapping database system. --> Dino Farinacci: We'll have to make a technical/operational/economic justification if LISP sites for IPv6 should not use this prefix. --> Ron Bonica (from Jabber): Every year or so somebody asks for a /8 for their favorite transition mechanism. It never happens. A /16 is doable. --> Dino Farinacci: This is not a transition mechanism. --> Joel Halpern: It has the same problems for this purposes, in terms of getting the allocation. --> Terry Manderson: I'll take it to the list to discuss according a /16 from the IANA as a reserved address space for LISP. --> Dave Meyer: You know I wrote a draft, a while back, asking IANA for a /8. I can resurrect it and make it a /16. --> Terry Manderson: yes I know. --> Joel Halpern: We have to discuss it on the list and then we may resurrect it. --> Terry Manderson: I have a contact in the IANA to who I can ask. When I'll have a response I'll send it to the list. --> Jari Arkko: This is really an IETF decision to make. If the working group thinks it is a good idea and last call goes through then we have a go. It's not an IANA decision. --> Terry Manderson: It's not an IANA decision, I was trying to understand the procedure they are going to expect. --> Joel Halpern: If we need it even sooner than when we get the document through the procedure we can ask Jari to ask the community to get us a prefix allocation even sooner if we need so. First, we got to figure out what we need and then we will figure out exactly how to do it. --> Jari Arkko: Yes, and in previous cases, like this ORCHIDS thing, one document does the allocation and the actual usage is on other documents. So there are other documents that employ this space so you can decouple them and you do not have to have like a normative dependency. So, all of the LISP documents do not need to be RFCs before we can do this. But I think is a good idea to do this as an RFC rather than an email discussion somewhere. --> Wes George: Is this something you can potentially use the class E space for? --> Dino Farinacci: Yes --> Jari Arkko: Yes --> Wes George: Because, we have this whole set of addresses that we cannot really use for anything and the argument is always "we can't use it because there is a bunch of stuff that will not work with it, because we got to make changes to the OS in order to make it work". Well, a lot of this stuff is falling in that category anyway. So it might be worth to resurrecting that discussion if we are going to ask for a /8. The other thing I would say is if we are going to ask for something that is in the current routable space, with such a limited amount of space left, you have absolutely to have an ironclad justification of why you need it. --> Dino Farinacci: I understand your point Wes. I do not think that the /8 in the 240/4 is the same case. The 240/4 are EIDs you assign to hosts, which means that the IGP routers would have to be modified. So a lot would have to change. With the /8 you have to deal with that only on the LISP routers, so it is less of an impact of a change. It is only in LISP routers. --> Terry Manderson: No more comments? --> Terry Manderson: So we are done.