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 so this is Chris Hopps and there is a mismatch in the document between the model and the tree. Chris will contact you Fabio and to show you the issue sso 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 so 1 month ago and then 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 because my understanding is that we are waiting for the discuss comment for the latest version to be reviewed and I think at this point is only Ben and Mirja. Debra :I forget myself did you actually send them mails ? Albert: yes I did Debra: in June ? Albert: In June yes. I can check it now again Debra: if you can this week try to grab them and asked 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 now but if you can get them this week you know that would be good in case they don't have a follow-up right to talk about it just because Albert: You are suggesting me to send them a friendly reminder right? Debra: Just say you have time to meet this week Fabio: May be just one additional comment on this GPE I have a set of comments from Mirja that needs to be applied at document and you know I just didn't take a chance to do those but I mean 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 6823 bis at 6833 bis. - 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 Ben and Med. Discussion: Fabio: To be honest I am not completely sure on the status of the LISPsec Draft at this point because we basically were told by the reviewer that the review of the Bis RFC's should go together with a review LISP SEC. We have got a bunch of comments we have incorporated that we received in Prague, I think that the next step is getting a feedback back from Ben and from the security Directorate. That's my understanding but we need to figure out how what is actually the next step É. Luigi: If you check the data tracker this document is in the last call for two months. we should clarify you whether or not taking Mountain moving it forward if the the new person replies to man you know step it up yeah it's ever Debra: I think it's really good that this is looking stable and I would give it a heads up then when you say to Ben and reminding him because I found in the mail. I think all of us want just say that this one's stable now too because that's what he really wanted . He was not sure the allocation of the different information. Fabio: right it should be in this document or the others so now you can have this document also to look to say that everything. Luigi: good yeah in it as far as I remember he was looking for our complete security solution for lisp and this was kinda missing piece. Debra yeah I will send him the heads-up for early review. Fabio: exactly that was my understanding again right that what they were really asking was to basically move forward this document together so that we have a overall view of lease that applying control plane and security okay cool any other questions okay thanks o 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: Basically the uberlay is an overlay it's specific purpose to connect. Alberto: that is correct Luigi: okay next question - can I have several uberlays connecting different site overlays and these uberlays can interconnect between them ? Alberto: that is an excellent question., 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. I mean theoretically yes but we have not addressed that yet on the draft. So that is on next step for us but that's a good question. 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: yeah 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 and deployed at uberlay É so me and you and Alberto and Fabio take we interconnect pairwise and we use different uberlay but in the future we want all to interconnect we become big family okay 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 I didn't say that I said you connect all the site overlays you take all their any EIDs and you sent 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 and I think that the answer is you will have is the two uberlays that used to be completely independent each other you will aggregate so you will end up with a single uberlay that connects the four site overlays right Dino: Correct. In other words, you merge the uberlays but that's what I wasn't suggesting. I was suggesting it's just one overlay yeah because the EIDs that are connecting this uberlay have their own local mapping system .. 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 a little bit. Dino: It is not clear as you still need it anyway for the original ... Luigi: This is something that must be discussed. I think that whatever solution we end up on the uberlay É Alberto: I agree that we are not addressing yet the use case where you have multiple overlays. I think that we're kind of saying the same thing here but if not clear Fabio: From a practical standpoint ,,, this is coming out of the International Civil Aviation Organization did by the way as the site. In that case, what I think will determine what you do is how LISP domains are related . 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 is exactly trying to get everybody to talk to each other. Now depending on how many domains and requirements É you can go to a single overlay or a single uberlay or maybe to the multiple É Luigi: I think in the draft the very end (you should add) if you don't want touch these specific points over each case then just state it. For example , what we do not consider in this document. Need 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 guys kept the borders they need to register the mappings from the local site overlays into the overlay 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. I'm thinking me because if we did a very good job when we have a massive scalable mapping system you don't need this Alberto: oh you're talking about the overlay so so that's that's fine Fabio: I mean if we say for in okay the overlay is gonna run at the planetary scale but there may be two organizations don't want to use the same . Alberto: Yes. We can say 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. Luigi: Can you clarify to me know what is the difference between federated and decentralized? Dino: In this case ,well the analogy I was going to get us look if you have 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 period topology altogether that would be the same as using uberlays. Alberto: The centralized comes from some the discussion that we are having with Victor and the iCloud 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 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. Albert: okay we need to agree though on the scope of the draft and what it is not going to address. Luigi: otherwise I don't think there is any specific issue in 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 catch miss because you send a packet with a larger TTL and you don't see any next hope or know that this has Dino: nothing to do with the original traceroute so itdoesn't use TTL mechanisms at all . Since it's not written up in a draft there's their source that you can look at. É. Albert: Do you have any plans to specify protocol 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. If it's useful should we write a draft. Prakash ??? Dino: It knows the number of hops.and there is another tool called LOC8tr that t can be used in conjunction. Possibility of using both tools in conjunction. Open 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 as you do not like in Montreal your iPhone is pointing to which PETR? Dino: will show in the demoÉ it did work when I was in 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 in the in the passage it's always the same PETR, I mean if it's your own then your traffic is going back to California you know 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. Dino: You mean should the PETRs should be dynamically learned based on your physical location? Luigi: Yes. This could be an issue so we have we have to think about this. I'm not asking for our solution for now. Another thing RTRs are configured by gleaning É Dino: RTRs are not configured by gleaning. 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. This a demo Éthis is not an RFC. Luigi: my point is that we have to keep this in mind because 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 so far Fabio, Luigi, Albert: É. Open discussion on gleaning , lisp document and real use case deployment. Dino ÉMobile node document it just assumes they're in this pristine environment which is not the Internet where theRLOCs 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 Todo List next Discussion: ??: Does Rloc Probing cause scalability issues in the network? Dino: Certainly less is better so not doing it is better than doing it. 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 multihoming because the network connectivity isn't good. I found that here a little bit too by roaming around was stuff wasn't working I'm going what's going on and it's the ietf hotel Wi-Fi network that's kind of bad so this is a great environment I'm gonna be doing testing in fact I'm going to be testing all this week if anybody sees me walking around and they want a quick demo right there I just have to pull out my wallet and boom or pull out my phone I could show you. Your point is taken should you just RLOC probe a few of them versus all of them because there's all those phones are going to be our look probing the same ones but I have a feeling we're going to have location-aware deployment to solve the Luigi problem . 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 ??: Exchange of LSP 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. Dino: you think there would be a compelling thing ? Luigi: 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: I have a small question 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 where the brings together the use of mobility with an overlay, the use of the mapping system to map something not as traditional as PID /RLOC mapping as we have done so far and also that try to take advantage of the locality of the service offer by the by the market servers that are that are storing the demand pin itself and then on top of that using single free multicast to basically reach a featured 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 but what I think is very helpful this use case here is bringing all together in one you still with a very clean practical application. I agree which around 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 right you want to have basic the mapping service that is highly distributed available at the edge of the network that offers you quasi real-time information so I think this is very general in many application that we see coming so that's why I think there is a lot of value in you know 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 you know there are new things that are needed it's very nice that so far most of the requirements that Sharon articulated seems to be addressed by what we have in the overall LISP so this is very useful I think activity for this working group. Dino: if we just wanted to publish this as a use case and made it informational RFC what where are the steps we have to go through does it require the working group does it not do you have any preferences? 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 how they 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 then 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 so I want 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 and appropriate Sharon: Just one comment on this 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 not that 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 group next time or something I've got to talk to folks I've talked to one of the ops ADs I've talked to some of the others I've talked to some of the geolocation people who've been involved turns out Richard Barnes whom I'm on another committee with is very it was very active in that we'll just will close the loop and find out the best way to move it forward. 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 a that's an it in the picture as far as I'm concerned.