CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Terry Manderson ( Terry.Manderson AT icann.org ) SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) Luigi Iannone ( luigi.iannone AT telecom-paristech.fr ) 9:00-11:00 Friday 15th March 2013. Session 1/1 (120 min) =-=-=-=-=-=-=-=-=- Note Takers: Luigi Iannone, Wassim Haddad, and Damien Saucez Jabber scriber: No Volunteers Note Well! Chairs => First set of 7 documents are now RFCs (6830-6836), congratulations to the authors, editors, reviewers and the WG. Chairs => Updates from IESG: - Document LISP EID Block is back to the Working group. - Document LISP MIB is pending a revised version. Agenda bashing ================================================= o WG Draft updates - Intro and Architecture - LISP Threats Analysis - LISP EID Block o Other related items and Drafts - LISP EID Block Management - Multicast Overlay Models & Mechanisms - draft-coras-lisp-re-01 - draft-cheng-lisp-shdht - draft-cheng-lisp-nat-traversal-extension - draft-arango-pim-join-attributes-for-lisp-00 - LISP gap analysis for nvo3 o AOB (time permitting) - LISP Based FlowMapping for Scaling NFV No Agenda Change Proposed. ================================================= - Intro and Architecture (Terry Manderson) Documents: http://tools.ietf.org/html/draft-ietf-lisp-introduction-00 http://tools.ietf.org/html/draft-ietf-lisp-architecture-00 http://tools.ietf.org/html/draft-ietf-lisp-perspective-00 ================================================= Terry Manderson => This is actually a consensus check to change the name of the LISP Architecture document to "LISP perspective". Hum consensus in favor of name change. Terry Manderson => Thanks. Please review both documents, it is very important to receive reviews. - LISP Threats Analysis (Damien Saucez) Document: http://tools.ietf.org/html/draft-ietf-lisp-threats-04 Slides: http://www.ietf.org/proceedings/86/slides/slides-86-lisp-1.pdf ================================================= Joel Halpern => When you talk about using mechanisms we already have you are talking about the published RFC plus the LISP-Sec document? Damien Saucez => Yes, something already published or under discussion but advanced enough. Is a good point, and helps in stating that LISP-Sec should be published as RFC as well. Darrel Lewis (on slide 10) => I think "severity" is a fine word. It is very understandable and clear, which is unique for a security document in IETF and we should wrap it up. Brian Haberman => I agree with Darrel that this is a unique way to do it for an IETF protocol. I was curious if you spoke with some security side of the IETF, so that there will be no surprises when we take it forward and publish it. Have you talked about it to anybody? Damien Saucez => No, not yet. Brian Haberman => We should do it to be sure that there is nothing we should be concerned about with this approach. Fred Templin => There is a threat where in a data packet you can have an EID spoofing even if the RLOC cannot be spoofed, is this considered in the draft? Damien Saucez => Yes, there is two levels of spoofing, the spoofing of the RLOC, the spoofing of the EID, but also both at the same time. We show in the document that by checking the mappings (before encapsulating or decapsulating) you can avoid this. Fred Templin => I think this is true only if the RLOC cannot change. If the RLOC can change, for example if the ITR it is behind a NAT or the ITR is mobile, the binding between the EID and the RLOC cannot be maintained. Damien Saucez => But you still have a mapping that associates to the address of the ITR. Fred Templin => And that address of the ITR can be changed. Damien Saucez => Yes, but for example using LISP Versioning you can know if it is a new mapping or not. You have to get the last version of the mapping to be sure you have the correct one. But we do not have a final solution for that, we need more discussion, because we cannot use the mapping when it changes otherwise is a security threat. It has to be solved. Fred Templin => Right. Where do you categorize it in terms of severity. Damien Saucez => At Level 1, because by configuration you can change it. Fred Templin => OK, so if a new Denial of Service is opened by LISP, then I would say that is a higher level of severity than 1. Damien Saucez => It depends if you want to remove the Denial of Service created by LISP, then if you can avoid it by configuration then it would be 1, if you have to deactivate the feature than it would be 2, if you have no way to solve it without changing LISP then it would be 3. It really depends on the threat you have. Fred Templin => Ok, may be is better if we take it to the list. Damien Saucez => OK. Luigi Iannone => Concerning the security review Brian brought up, we tried in the past to have a review from the security guys but did not work out. So, it would helpful if Brian can point out someone willing to do a review of the document. Differently from my co-author I think the document is ready for Last Call. In any way the document is ready for a security review. Joel Halpern => It would if authors can send the severity levels definition to the list asking people to look at the proposed severity levels because is something new and we really need to make sure there is agreement on it. Luigi Iannone => Slides are publicly available. Damien did a great job describing for each severity level which threat goes in this category, so is just a matter of reading the document and having this slides at hand. Of course we need to discuss it on the mailing list. Joel Halpern => That is why I am called attention on it because people do not look at the slides especially if they do not attend the meeting. We need to discuss this on the list. Luigi Iannone => By the way, Damien was so kind to share the slides with the whole mailing list. Joel Halpern => And we appreciated. Terry Manderson => Disclaimer for the next two presentations: This WG does not get to talk about "who" in terms of EID management. This is not in our control and is not in our responsibility. We can talk about technical parts of how, but certainly not who. - LISP EID Block (Luigi Iannone) Document: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-04 Slides: http://www.ietf.org/proceedings/86/slides/slides-86-lisp-2.pdf ================================================= Terry Manderson => How are we going to enforce that the EID block will be announced only in case of inter-working, in large aggregates and only by PxTRs? Luigi Iannone => Let's postpone the question to the next slot because in my opinion is more about the "how" we allocate the space and the requirements that we define. Joel Halpern => We are asking for EID in the v6 addressing space. For this to be useful people have to believe that this is relevant for v6. Another question is whether 10 years is really a reasonable time for an experiment. It feels awfully long for me! Luigi Iannone => Concerning the length of the experiment, we really need operational experience and in my opinion have the prefix for like one year is not enough. Concerning LISP for IPv6, the starting point of all this effort was scalability of BGP, mainly related to IPv4. But LISP provides other benefits, discussed in the first documents you chairs discussed at the beginning today, so I think that we will use LISP in IPv6. John Curran => Two questions. First question concerns the paragraph about the use cases describing the potential use of proxy routers to announce it; is the assignment of the block only useful if the block is also announced in the traditional BGP routing table as well? Luigi Iannone => We do not need to announce it in BGP. John Curran => So is a possibility is a COULD. Luigi Iannone => Yes, you do it if you really need to ensure interoperability between the EID space and the non-EID space, does not mean you have to. Joel Halpern => This goes in another document on our plate: the deployment document, which talks about interworking models. If we assume we are going to get the EID Block, PITR will need to announce that. If they are serving some EID reserved space, which is not regular addressing space they need to announce it otherwise we do not have interworking at all. So some form of aggregate advertisement will be needed if we assume the deployment model of the deployment document. John Curran => OK, fair enough. Second question has to do it with the model chosen for experimental assignment as for RFC 3692 (BCP 82) that Scott Bradner asks me to bring it up since he cannot attend. Luigi Iannone => That document does NOT apply here. I did not remember the RFC number back in the Intarea meeting, but I read that document but went over it again. I really do not think that this document applies here because we have different requirements. Secondly, as a personal opinion on that document, if I have to do an experiment by using overlapping IP addresses, I rather go for private addresses without bothering IANA. So short answer is that it does not apply. John Curran => The document BCP 82 has a paragraph warning about doing experimental assignment to external organizations and proposes an alternative at the bottom. For people using experimental assignments make a lot of sense, but what you are proposing does not look like what the IETF calls an experimental assignment because potentially is a very long permanent thing. You reference this BCP in the EDI Block part, but you actually go the on the path it does not recommend, and somehow this should be documented in this draft. Luigi Iannone => So we can add text that says that BCP 82 exists, states that, but does not apply here. John Curran => Stating why does not apply is probably a good thing. Luigi Iannone => Sure! Brian Haberman => I don't have an issue with the size you are requesting as we already have assignment of that size in the special registry you mentioned. As an example there is the ORCHID address space that has a termination date on it. Is not designed to be rolled over to a permanent allocation. I would expect a large push back if we ask IANA for an experimental allocation and in a few years we say that the allocation is actually permanent. In the ORCHID allocation, there is an ending date and that space is not routable and we had to twist harm to make that a 7-year allocation. So I do not see 10 years as a reasonable amount of time for something considered an experiment. Luigi Iannone => So what are you suggesting? Brian Haberman => Less than 7. Luigi Iannone => This leaves us with 7 possibilities :-) Concerning the point about asking a temporary allocation and at some point change our mind. I do not think is the case. What we need to do, not in this document but on the next one, is how to move from a temporary allocation to a permanent allocation. This is something we need to document from today, stating clearly that this is a possibility. We need to document that in 7 years we need to take a decision on this specific point. Concerning ORCHID, I think it is a good example and is a bad example. As far as I remember, in ORCHID addresses are generated algorithmically, this means that even if you give back the prefix and take another one, it is still something automatically generated, so it is not about giving out chunk of addresses. But I might be wrong on this. Brian Haberman => The size of ORCHID was decided based on the size of a cryptographically generated piece of information. Further, the 3FFE space was experimental and was shutdown 7 years ago but it is still in the routing tables. Luigi Iannone => This is a good point. But I feel we are shifting the discussion on the topic of the next slot. But we need to document all cases, whether we go permanent or we go back. Brian Haberman => The point is not about management, the point is that when me make these allocations, no matter how much good faith we put into it, saying "this is what we are going to do" does not necessarily means that everybody will follow. Luigi Iannone => Fair enough. Darrel Lewis => I think personally we should review the benefits of all of this, because nobody will give addresses back. This looks like a lot of work for a modest implementation benefit in some device talking with some other devices. I can see the deployment benefits and the attractiveness of the space for end users that want EID space. I can see it for some implementation that may create some shortcuts. I am just not really sure if they are worth it. Terry Manderson => Let me jump in with a question I had for a while: what is the difference between "need" and "want"? Does this experiment need this allocation vs. does this experiment want this allocation? We should be 100% sure that this is a need allocation. If it is not I would ask the WG to set aside this document. Dino Farinacci => I think definitely it is a want and not a need. And when we use the expression if LISP succeeds on the Internet, EIDs will be used for IPv4 and IPv6, those addresses will be addresses that people have today. So this block is not being used to decide the success of IPv6 LISP. It is used for an optimization in the ITR. So we do not need it, but we want a box, an ITR, that talks to non-LISP sites, we do not want them to take the hit, we want that packet flowing to legacy non-LISP site do not take the lookup overhead. That is why we want this block: ITRs can assume that there are xTRs deployed in that site. So it is definitely a want and not a need. Do we want to optimize this? Probably. Luigi Iannone => I would like to add that I totally agree. Is not something that without LISP would not work. Also on the point on whether or not we keep this IPv6 allocation does not mean that the whole LISP architecture is a success or a failure. Having said that, we can see some benefits in having it, and I think we do not have yet the complete picture of the full implication of the LISP technology, so having a prefix we can discover new use cases and becoming more useful in the future as long as we can experiment of that. So if this is an experimental protocol, let's have an experimental prefix that goes with it. John Curran => I disagree. It is a want but it may be also a need. If you want that LISP becomes everything you want it to be, you need a transition plan from the current Internet to the LISP global Internet, that is a bigger goal. When we did v6 we bumped on transition. We initially had zero and we ended up having 20 different transition mechanisms none of which was really architected. I do not know if this block is a want or a need, am guessing is a want, something to playing around with. But at the time we do a LISP deployment without a LISP transition strategy that does not say whether this may be announced or could be announced, this is how the block will be used. If there is a transition strategy, then it becomes a must have. What am saying is that it is probably a want right now, I am very nervous with people saying we are going to have it and we are going to play with it and it is going to be potentially permanent. I think you need to decide this is the transition block and the transition plan and be very serious about how does it work. Or you say is temporary is going to go away and people will have to renumber out of it. Dino Farinacci => About what Luigi said about new use cases. I think we should try to be open minded about it. Having said that, should we ask an IPv4 prefix for the same reason? Luigi Iannone => We do not have this luxury. Joel Halpern => To phrase it differently: we cannot ask for a block because we think we will have some use cases at some time. Luigi Iannone => If you have any use case you thing is worth please comment on the draft. Terry Manderson => Transition strategy should be in there. - LISP EID Block Allocation (Luigi Iannone) Document: http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 Slides: http://www.ietf.org/proceedings/86/slides/slides-86-lisp-3.pdf ================================================= Darrel Lewis => I had some feedback from private providers and what I have heard is that would be nice to say that the allocation MUST NOT be announced by the site itself into the DFZ. Luigi Iannone => You want a MUST on that? Darrel Lewis => MUST NOT be announced by the site itself as a routable EID. Luigi Iannone => Sure, good point. Arturo Severin => One important requirement that we might want to mention is that if we want LISP to succeed in the future, bringing the allocation from experimental to production, you have to have that requirement there. Whatever you do to allocate those EIDs, you have to move to production in the future. For experimental, whatever solution would probably work, but if you want to move to production it is going to be more complex. As an ISP, if they say we start to use LISP and in the future you say that they have to move they will reply: no. But if you assure them that that allocation will go to production and they do not need to do anything, this would be more appealing to them. Luigi Iannone => May be this is one of the few points that are already in the document. Avoiding renumbering when we switch for a permanent allocation. But is still a point that needs more work and text. Darrel Lewis (on slide 7) => We (Cisco) donated an IPv4 /16 and a /32 for IPv6. So with the power of 500 USD per year, we have an experimental prefix. Whoever wants can always join the beta network and have a part of it. John Curran (on slide 5) => That is a great list that David Conrad gave. A couple of more things to think about. However the allocation is done what we need to know is the requirements of how these allocations are made. Are they sparse? Or are they consecutive? If they are sparse, are they sparse by maximum distribution power of two, by geography, or by country and corporation? Think about that because whoever does it needs to know that. Otherwise there will be surprises if the allocations are done consecutive and this is not what you expected. This is a technical requirement and this is something that any allocation authority needs to get done in order to do the job. Another one is re-use. If something comes back in can be put back out the next day? Are there technical issues? Maybe not. Under services, you mentioned reverse DNS and whois. Is there a need for resources certification of some form? The reason I ask is because my mapping entity might want to know that I am the one that actually has the block. This opens up something I am not sure we want to talk about, but is worth mentioning it. Joel Halpern => There is a section that is clearly related this stuff in the DDT document, and it clearly has to be tight with the allocation document. John Curran => Exactly. Now, two other nits. "Allocation service must be provided at no more than cost." For your information RFC 2860, between the IETF and ICANN, sets the allocations for free unless the IAB approves otherwise. No more than cost is fine, but even for that, we need an IAB decision. Last aspect (on slide 6), if this allocation is not going to ever show up in the traditional v6 routing table, then you need a specialized technical assignment, rather than a temporary or permanent, they are not much different for the existing operator community than multicast or loopback or anything else. If these do show up, not that I am saying that it will, but that it could, that calls for the term policy issues. I am not sure whether it is within the IETF ability to make these assignments to make an agreement on policies without further consultations. Andrew Sullivan => On slide 5 you had suggested that reverse DNS should be provided, and I am wondering why? What are we going to do with that. I am asking this because there are people trying to deprecate the reverse tree, and I am trying to figure out what the value is for this specific use case. Luigi Iannone => More than reverse DNS we need reverse mapping. Meaning that if I have an RLOC or another piece of information I may want to know who is managing that allocation and who is responsible for. Anyway, this is just a starting point for discussion, not the final list of requirements. Andrew Sullivan => What you are saying is that you do not need reverse DNS. Your problem is to know who is responsible for this space. Luigi Iannone => Yes, but anyway, EIDs will be in the DNS system because we will deploy in the EID space sites that we will access through the DNS. For that we probably need reverse DNS, without the need to document this here. Darrel Lewis => Do you think this allocation would enable use cases that aren't in the deployment guide? Because if there is a one-to-one match then it seems to me, we can leverage on that document to write the requirements in this document. Joel Halpern => Speaking as a participant, I wonder if we should include in this document, at least as an open question, the relation between allocation policy to mapping system operation. Because there are relation in people head that I am pretty sure they do not match each other. Luigi Iannone => OK. Luigi Iannone => What is missing? What we did not discuss and we should discuss? Like the last point of Darrel. Terry Manderson => Can you please repeat those questions on the mailing list? Luigi Iannone => Sure Terry Manderson => Thank you! - Multicast Overlay Models Mechanisms (Dino Farinacci) Document: http://tools.ietf.org/html/draft-farinacci-lisp-mr-signaling-00 Slides: http://www.ietf.org/proceedings/86/slides/slides-86-lisp-4.pdf ================================================= Joel Halpern => Quick question: do we handle the case where a site has multiple RLOCs, but only one RLOC is actually handling the multicast. Dino Farinacci => Yes, we do. In the specification we have priorities and weights like in the unicast case, so we can handle the case. Darrel Lewis => The other draft (draft-coras-lisp-re-01.txt) has some enhancements on that. Darrel Lewis (on slide 19) => Is the path from EID space to EID space will always be either unicast or multicast? There is any option to go native for part of the path then encapsulate and go unicast for the rest of the path? Dino Farinacci => We may have to do that, there might be a pat that is multicast in the middle. For Instance, if a holistic controller says that B and C are downstream of A, then they can do the replication for D and E. This is what, with an offline analysis, a controller can do. Brian Haberman => The AMT document is stopped right now. People have concerns about congestion control when doing multicast over a single unicast tunnel. So something to consider is whether or not something should be done when multicast goes over the overlay and is encapsulated on a unicast tunnel, to alleviate that fear. Dino Farinacci => It's kind of funny this argument. Not because you described it wrong. The description "all this multicast packets in a single tunnel" is misleading. Is not a single tunnel with a hardware capacity limit, is a unicast header prepended to multicast packets, they can be load split across the core. Looks like a non-problem or a dramatized problem. Brian Haberman => Understood. But there are people concerned about the potential congestion control issue. I am not saying you have to do something, but do not be surprised if people from that side of the IETF say that it is an issue. Dino Farinacci => Thanks. - LISP Replication Engineering (Dino Farinacci) Document: http://tools.ietf.org/html/draft-coras-lisp-re-02 Slides: http://www.ietf.org/proceedings/86/slides/slides-86-lisp-5.pdf ================================================= Joel Halpern (on slide 8) => Is there some special reason why the ETRs join always at the leaves? What if an ETR joins the closest RTR, which might be L0 or L1 in the example. Dino Farinacci => We want to give control to the core network operator. The ETRs are going to be customers that join in and we want that the service provider is going to decide what is the best. Joel Halpern (on slide 8) => So is the construction of the tree, e.g. 22 joining 11 instead of 12 based on some other configuration or on the list of (S-EID, G) RLOCs? Dino Farinacci => Is based on priorities, where for the same priority you can use some hash load balancing. Then you can use some coarse closeness algorithm to decide which RTR to use. Joel Halpern => An operator controlling this wants to decide which RTR is joining which RTR because that's clearly tight to their network topology and the list does not seem to be enough information to get that result. Dino Farinacci => Right. Darrel Lewis => You made a comment about everybody always wants the shortest path, obviously operator want to optimize its bandwidth, but am not sure the S-EID ITR does necessarily care about the path inside the service providers. So an ETR may want to join an ITR because it simply works, at least until it does not run out of replication resources. Dino Farinacci => Yes, but we want to keep the customer edge as simple as possible otherwise we will have problems. We have seen this before. We want that service providers use bandwidth with maximum efficiency. Darrel Lewis => You are talking about the bandwidth efficiency of which link? Dino Farinacci => We want that ITR send a single packet that is then replicated in the core network. Fabio Maino => If you want to use bandwidth efficiently you build a static tree. Dino Farinacci => There is a lot of advantages in using a unicast encapsulation, because packets are going to use ECMP. Darrel Lewis => Many time what we found is that operators do not want to save bandwidth at the first hop between ITR and RTR. Is the other way around, the source ITR is running out of bandwidth and wants help, to avoid upgrading the link. Dino Farinacci => The question that could be asked is whether to put the (S-EID, G) in the database today, like you do with LISP Multicast and then you send a join. Should we allow that vs not? We need research. Joel Halpern => Normally the site own the (S-EID, G) entry, but in this environment some combination of operators need to provide input that needs to be included into this data. Dino Farinacci => Yes a really insightful point. Operators need to create this (S-EID, G) entry and need information from the source ITR. So there is some form of interaction that has to go on there. Joel Halpern => So the site is signing the entries but the operator has to create them. Dino Farinacci => Yes. Anoop Ghanwani => There are two extremes. One is where there are no RTRs and the ITRs do all the replication and there is no need of new equipment in the provider network. The other extreme, is the case is where every router is an RTR and at every hop you need to change the tunnel addresses. Dino Farinacci => That makes the question should every router be an RTR or should every router be a multicast router? I have no answer but this is a good question. Anoop Ghanwani => If you do that, you still do multicast routing but you have the advantage that you do not need to manage group addresses in the outer IP header. Dino Farinacci => Very good point. Anoop Ghanwani => On the flip side, all of those RTR need to become aware of the inner (S, G) groups, to route things most efficiently. Dino Farinacci => This leads to asking whether we can get rid of routing protocol in the Internet and just use LISP at every hop and encapsulating. This is like doing MPLS at IP level. May be something to think about. Thanks. ================================================= Terry Manderson => We are running out of time, so we better close here. Those that were supposed to present today will have priority in Berlin (IETF 87th). Joel Halpern => Presentation material is available, for people interested. [Session closed] =================================================