IET 105 LISP WG Meeting minutes CHAIR(s): Joel Halpern (jmh AT joelhalpern.com) Luigi Iannone (ggx AT gigix.net) SECRETARY: Padma Pillay-Esnault (padma.ietf AT gmail.com) AGENDA Session 1/1 (120 Minutes) =-=-=-=-=-=-=-=-=- Monday, July 22, 2019 13:30 - 15:30, Afternoon Session I, 120 Minutes Room: Notre Dame - Administration Halpern/Iannone - Blue Sheets - Agenda Bashing - Status reports for WG drafts 5 Minutes (Cumulative Time: 5 Minutes) Luigi: RFC 8113 this is now in the RFC queue just waiting for a missing reference . Yang model is under review a yang doctor, Chris Hopps, and there is a mismatch in the document between the model and the tree. Chris will contact the authors to show the issue so that this can be solved. WG Items - Update on 6830bis/6833bis documents - https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-27 - https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-25 15 Minutes (Cumulative Time: 20 Minutes) Albert Cabellos Albert presented a summary of the updates on 6830bis and 6833bis since last IETF. A new version of each of those documents both in June 2019 was posted, hopefully addressed all the comments made by the reviewers. Changes summarized into four main items: Security, rate limiting, MTU, and other. Discussion: Fabio: Just trying to understand what are the next steps. We are waiting for the discuss comments for the latest version to be reviewed by Ben and Mirja. Deborah: Did you actually send them mails? Albert: yes I did. Deborah: June? Albert: Yes. I can check it again. Deborah: If you can this week try to grab them and ask if they had a chance to look at it. I'll try to remind them - and definitely next week we'll get on or more because everybody's very busy right before the meetings but we try to get them to clear them. But if you can get them this week, it would be good. Albert: You are suggesting me to send them a friendly reminder right? Deborah: Just say you have time to meet this week Fabio: May be just one additional comment. On GPE I have a set of comments from Mirja that needs to be applied at document, and I just didn't have a chance to do those, but they're in the queue so I hope I can do it shortly after. I would like to keep these in with the review and aligned with the 6823bis and 6833bis. - LISP-Security (LISP-SEC) - https://tools.ietf.org/html/draft-ietf-lisp-sec-18 10 Minutes (Cumulative Time: 30 Minutes) Fabio Maino Fabio presented the updates in response to comments from Benjamin Kaduk and Mohamed (Med) Boucadair. Discussion: Fabio: Not completely sure on the status of the LISP-SEC draft. Because we were told by the reviewers that the review should go together with the review of the bis documents. A bunch of comments received in Prague have been incorporated. We think that the next step is getting a feedback back from Ben and from the security Directorate. Luigi: If you check the data tracker this document is in the last call for two months. Clarification is needed on whether or not moving it forward. Deborah: It's really good that this is stable and I would give it a heads up, when you say to Ben. Fabio: So now you can have this document also to complete everything. Luigi: As far as I remember he was looking for our complete security solution for LISP and this was kinda missing piece. Deborah: I will send him the heads-up for early review. Non WG Items - LISP Uberlays - https://tools.ietf.org/html/draft-moreno-lisp-uberlay-01 20 Minutes (Cumulative Time: 50 Minutes) Alberto Rodriguez Natal Discussion: Luigi: Can I have several uberlays connecting different site overlays and these uberlays can interconnect between them? Alberto: This is actually in the list of next steps. In the draft right now we consider a single overlay. We have discussed on what to do with multiple uberlays. That comes with a different set of requirements and assumptions that we need to evaluate. Dino: It turns out to have multiple uberlays is less desirable than to have good multi-home connectivity on the underlay that the uberlay realizes because the uberlay is just there to connect the edge points of the other overlays and nothing else. It is not clear that you need separate policy where you need a separate uberlay infrastructure to interconnect so that's why we first started off that we needed one. Luigi: I understand that you start with the simple solution but my point is not that you need several uberlays. What can happen is it for whatever reason you have different overlay sites and they decide to interconnect. Let's say me and you and Alberto and Fabio we interconnect pairwise and we use different uberlay but in the future we want all to interconnect we become big family. Now, what you do? You deploy a new unique uberlay or you interconnect the uberlays? Dino: What you do is you interconnect the site overlays in another mapping system. Luigi: the uberlay? Dino: No, you connect all the site overlays you take all their any EIDs and you send them to a new mapping system and it looks like a regular overlay rather than to iterate this pattern again. Albert: I think that Luigi's question is that you have two completely separate uberlays like the picture you have here but two different ones so you have two overlays connected here to here right. Then at some point you want to bring the four different sites overlays together. You will have the two uberlays that used to be completely independent from each other, now aggregated so you will end up with a single uberlay that connects the four site overlays. Dino: Correct, you merge the uberlays but that's what I wasn't suggesting. I was suggesting it's just one overlay, because the EIDs that are connecting this uberlay have their own local mapping system and they could register to a mapping system that's global and it just looks like a regular LISP overlay as we know it today. Luigi: You kill at least one of the uberlay and you keep the other one. Dino: It is not clear, as you still need it anyway for the original reason. Luigi: This is something that must be discussed in the document. Alberto: I agree that we are not addressing yet the use case where you have multiple overlays. Fabio: This work is coming out of the International Civil Aviation Organization. In that particular case for example the requirement is that there are some LISP domain that they will not become the same because there may be different providers. The first level is trying to put them together with an uberlay, yet it is exactly trying to get everybody to talk to each other. Depending on how many domains you can go to a single overlay or a single uberlay or maybe to multiple. Luigi: I think in the draft needs to say something one way or another. Authors request discussion on the mailing list and would like to know if the working groups will take upon this draft and make it a work group item. Authors invite discussion on next steps points. Luigi: For clarification: what do you mean by improve state reduction in uberlay? Alberto: For instance, think that you have multiple ways to register. (on slide multi-overlay control plane) these sites at the border need to register the mappings from the local site overlays into the uberlay and you can take different approaches for that so you can register the mappings as you get them from the local site or you can try to aggregate as much as possible. If there are gaps, you need to register the gaps and so on. So we need to discuss which is the best way to reduce the state you need to release it into the uberlay. Luigi: Okay. If we did a very good job when we have a massive scalable mapping system you don't need this. Alberto: If you're talking about the overlay that's fine. Fabio: You can have an overlay that is gonna run at the planetary scale but there may be two organizations don't want to use the same mapping system. Alberto: Yes. Let's put it this way: if you don't want to aggregate anything that you're gonna really need then a mapping system that is able to scale to a global scale, so that's the kind of considerations that we need to think of. Dino: We can have the analogy with a single BGP process that's running with multiple VPNs. You can keep the VPNs separate but they're shared by one process and one routing protocol but if you ran two BGP routing process that are completely separate it may have a different topology altogether that would be the same as using uberlays. Luigi: Can you clarify to me know what is the difference between federated and decentralized? Alberto: The centralized comes from some the discussion that we are having with Victor and the cloud guys. Latest discussion is about how the organization can deploy its own site in an overlay and then the uberlay is federated. So that no organization has control over the uberlay. Still under discussion lot of open questions still. Luigi: There is some work to do on this document. Still need much discussion on the mailing list if we want to go for the adoption. Should define what is missing and discuss on the mailing list. Alberto: We need to agree on the scope of the draft and what it is not going to address. Luigi: Other than that, I don't think there is any other specific issue that should be covered. - LTR: A LISP Traceroute Tool - https://github.com/farinacci/lispers.net/blob/master/docs/ltr.pdf 15 Minutes (Cumulative Time: 65 Minutes) Dino Farinacci Dino Presented a demo of the tool. Discussion: Albert: I guess that you infer that there is a map cache miss because you send a packet with a larger TTL and you don't see any next hop. Dino: The tool has nothing to do with the original traceroute, so it doesn't use TTL mechanisms at all. It's not written up in a draft, there's the source that you can look at. Albert: Do you have any plans to specify protocol changes that you need in order to implement that, because I understand that this doesn't work with a standard LISP. Dino: Right it would not. It's absolutely true that the forwarding implementation has to change to understand the trace. We can certainly write a draft if the working groups interested in it. Prakash: Does it understand also the underlay the LISP packet is travelling on? Dino: It knows the number of hops. There is another tool called LOCator that can be used in conjunction. I am open for discussion on possible uses and integration of this tool and what information is useful. - LISP Mobile Node - Demo 15 Minutes (Cumulative Time: 80 Minutes) Dino Farinacci Discussion: Luigi: Clarification: you have LISP mobile node on your iPhone but you do not live in Montreal, your iPhone is pointing to which PETR? Dino: Will show in the demo. It did work when I was sitting in Montreal. It worked on the cellular network . Luigi: how do you change it? Because basically you may have a long stretch if it's always the same PETR, I mean if it's your own then your traffic is going back to California, even if you are connecting to something that is here. Dino: Yes. I already experimented where that was very interesting the RTT is doubled yes. You mean should the PETRs should be dynamically learned based on your physical location? Luigi: Yes. This could be an issue. We have to think about this. I'm not asking for a solution for now. Another thing RTRs are configured by gleaning? Dino: The XTRs are gleaned and the RTRs have a command saying glean the information from us. Joel: We have the document says not to do that. Dino: The document says not to do that in public domain. Luigi: We have to keep this in mind if you want to move to the document forward. We cannot have the basic specs that say you should not use this and another document is technology is based on something you should not use. Dino: I understand your point but we're not violating anything. Dino: Mobile node document just assumes they're in this pristine environment which is not the Internet where the RLOCs that the mobile nodes registering are all in global space. So I mean a lot of these documents don't reflect reality. Demo. Caveats discussed: - Lisp Mobile mode must send before it can receive - Latency exists to learn LISP-MN when it is discovered -Asymmetry problem Discussion: Prakash: Does RLOC Probing cause scalability issues in the network? Dino: Certainly less is better. Apple does a good job of testing the Wi-Fi signal and if it's not good it automatically switches to LTE to give you some better performance. Should we be smart enough to know that the PETR aren't doing well with RLOC probing, which may be your point, and maybe turn it off and then try to go native. But then you lose a session survivability multi-homing because the network connectivity isn't good. Your point is taken should you just RLOC probe a few of them. So maybe not all the phones in the world are gonna probe the same for RTRs or the same hundred RTRs they're going to be local based Prakash: How to exchange of LISP cryto keys? Dino: I don't know how we're gonna exchange lists crypto keys dynamically without RLOC probing but unless they're PSK static or something like. Luigi: How do you exchange keys? Dino: They are public keys it's diffie-hellman exchange it's like TLS does so it's no different. The private secret keys are built independently. Luigi: Crypto would be nice to see. Luig: I had a second question about multiple multiple IEDs and multi IID. When I install a new application I have to figure out which key ID to use which IID to use? Dino: Defaults to adding that but it could add any type of routes it have to be destination based. You would have to say anything that so if I'm a cisco employee anything that goes a Cisco use my VPN now. How to do it seamlessly for the user is up to implementation. Luigi: Do you need to jailbreak your iPhone to install this stuff? Dino: You can download the latest version at the app store so if anybody wants to try it go ahead and I'll give you the addresses of the RTR actually you already know them. So I'm expecting a DOS attack after this [Laughter] - Distributed Geo-Spatial LISP Blackboard for Automotive - https://tools.ietf.org/html/draft-barkai-lisp-nexagon-05 20 Minutes (Cumulative Time: 100 Minutes) Sharon Barkai Discussion: Fabio: I want to make a comment on why I think this use case is very interesting for LISP. We are seeing a use case that brings together the use of mobility with an overlay, the use of the mapping system to map something not as traditional as EID/RLOC mapping as we have done so far and also that tries to take advantage of the locality of the service offer by the market servers that are storing the demand itself. Then on top of that, using signal free multicast to basically reach efficiently all the devices that are subscribed to a certain information. So it's a combination of use cases that are basically bringing together things that in the last few years we thought were possible with LISP. I agree that this is specific to this particular use case but I think is not very hard to think of other use cases that are not related to vehicle mobility and traffic road conditions that may have similar attributes. You may want to have a basic mapping service that is highly distributed available at the edge of the network that offers you quasi real-time information. I think this is very general in many application that we see coming. That's why I think there is a lot of value in working on this use case and basically trying to see how all the things that we have done in the LISP working group fit together and it would be interesting to see if there are new things that are needed. It's very nice to see that so far most of the requirements that Sharon articulated seems to be addressed by what we have in the overall LISP. Dino: If we just wanted to publish this as a use case and made it informational RFC what are the steps we have to go through? Joel: The question of how to advance the document turns on a different point than the IETF procedures in terms of our Charter. It's okay we could publishing the informational document because this deals with geolocation topics. I'm trying to find out from the geolocation experts here at the IETF. We may want to make sure that appropriate review from the teams who have dealt with these problems before because this is not a new topic to the IETF. The usage is new but the general topic of communicating information about geo locations and such like his one that they've worked on a lot. I'm going this week to talk to some of the people who've been involved with that historically and figure out a good path because when speaking personally, not as chair, I like the work, as chair I need to figure out what the best way is to get the appropriate review. Sharon: It's true it's geo state but the thing here is that it's a brokered Network meeting. It is shared state there's not very geo state Joel: Historically there's been sensitivity when we deal with geographic information so I want to make sure we get the review and involvement for people have been in that space and I don't care which working group ends up owning the problem. It may be that what we'll do is ask you to present this material at the ops area next time or something. I've got to talk to folks. I've talked to one of the ops ADs. It turns out Richard Barnes, whom I'm on another committee with, was very active in that area. Sharon: On a personal note appreciate this peer review to keep grilling this thing. Joel: We're not gonna throw you out of LISP don't worry . Dino: Was that a response to making it informational or just any type of work? Joel: Just whatever type, it looks to me like it it's mostly informational it needs just to find a new LCAF but that's all and the LCAF for registration procedures would allow that but that's not in the picture as far as I'm concerned.