LISP WG IETF 109 Minutes CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Luigi Iannone ( ggx AT gigix.net ) SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com ) o WG Items - Update on 6830bis/6833bis documents - https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ - https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ 10 Minutes (Cumulative Time: 15 Minutes) Albert Cabellos Albert C. gave a brief update on the progress of these drafts. Both documents have Discuss and he expects after addressing those discuss to be done with the document. Discussion/Questions:None - Publish/Subscribe Functionality for LISP - https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/ 15 Minutes (Cumulative Time: 30 Minutes) Alberto Rodriguez Natal Alberto presented the changes since -05 version. These are Removal of deployment assumption of pre-established security, Added mechanism for security associations via LISP-SEC for PubSubKey and PubSubNonce is now kept per xTR-ID +EID-record. He also presented the outcome and comments from early SECDIR review. Some clarification on use of the term “nonce”. There is some inconsistency on usage of the term in LISP doc (random but in some cases more like a token and can be reused,stored..) and RFC 4949(random and no reuse). Alberto asked the WG’s view? Albert C.: We have the same issue in the big documents but as it has been used in the past for a long time so it seems to be accepted but doesn’t know if it applies here. Luigi: Proposed that it might be good to use “nonce” in this document to be consistent with the base LISP spec. Proposed we should add a sentence that says we use this term nonce to be consistent with the base specs of LISP and that if we look at the RFC 4949 this would be characterized as a token. Alberto: Works for me. Dino: Thinks we should not change it at all and there is a large number of occurrences of nonce all across the documents. Just busy work. Alberto: SECDIR 2nd Comment on the value exceed the field space but it looks like they will last for a very long time. Luigi: Suggested to add that if it does wrap around to say in the doc what to do for completeness. Dino: In previous protocols, when there is a sequence number is wrapping around then you check with your previous number and see the difference and detect the wrap around. Albert: Makes perfect sense. Alberto: Feels the doc is ready for last call. Matt: proposed to fix these and take it to the last call - Network-Hexagons: H3-LISP GeoState & Mobility Network - https://datatracker.ietf.org/doc/draft-ietf-lisp-nexagon/ 15 Minutes (Cumulative Time: 45 Minutes) Sharon Barkai Sharon gave an update of changes since 108 meeting Discussion: Sharon: Given that we want to mark this problem and move on. Every problem has its own tiles, feeds, channels etc., would like to finish the hexagon draft and move it to be an rfc. Do we have to wait for base spec or can we publish this as is? Or refer to the bis in the generalized draft? Joel: if we try to publish any LISP drafts that are pointing at the current experimental RFCs even if those drafts are themselves experimental the IESG is going to look at us and say go wait but you're having us work on all this other stuff. I understand why you want to get it done and I sympathize but I really think you should be pointing at the bis drafts and get everything done. We're close enough don't worry about the time difference. Sharon: OK Alberto: Quick comment, don't have an opinion I just raised the point on the intended status of Nexagon draft right now is informational not experimental so I don't know if we still have to wait for the bis. Sharon: I'm perfectly fine waiting Luigi: I don't know if we need to. My personal opinion honestly is even if It is informational it would be better if it points to the bis documents. Just for more credibility for the content because at some point somebody could read and say yeah that is based on the old specs not the proposed standard. We are close enough, worst case will sit a little bit in the editor queue. Sharon: It's your consideration is your decision. I understand what Joel said just be aware of the other side of it. which is if you want to hand off this nexagon as an RFC to organizations like AACC, the auto edge, or anything that IETF is not in their industry it's not like dealing with Juniper and Cisco. The minimum has to be in RFC. So until then you know it's really delaying it so you know just um observe the progress and if it's reasonable then fine or not just make a call up to you. Luigi: Again I will give you my personal opinion okay these documents are very close to being done. I would wait a few weeks just to see if the Albert just submitted new versions maybe today or tomorrow they clear all the discuss. Please have a look to the new versions okay so maybe in a couple of weeks these documents are through so if you move your document right behind it's just two weeks delay I mean it's not a big deal but again this is my personal opinion Sharon: all right o Non WG Items - NAT traversal for LISP - https://datatracker.ietf.org/doc/draft-ermagan-lisp-nat-traversal/ 15 Minutes (Cumulative Time: 60 Minutes) Albert Lopez Albert Lopez presented the motivation of doc and updates. The doc is now very close to be completed Albert C: Commented that to his knowledge there are at least 2 implementations and that the draft is still an individual contribution and would like to ask for the WG adoption. Luigi: Excellent question. Like the work done, this is based on the pain you experienced. Last time Dino also presented a universal solution. So, Dino what are your plans? Dino: If you are asking about my implementation plans, I am not going to implement because the performance of the system is going to be way worse than what we have because of all the intermediate processing that has to be relayed through the RTR. Fundamental point, there is too much indirection of messaging and I showed an alternative solution that performs better. Handoffs are really important if you want fast convergence. Luigi: What do you plan to do with your document? We cannot have 2 documents to discuss the NAT traversal so at one point the WG will have to discuss whether to merge the documents. Dino: What I presented last IETF and doc, I will support whatever the WG wants to do with. Not sure I will support a merge as you will need to do the pros and cons of each one merge it. That would be a lot of work and compromise the design. You will have to go through the pros and cons of each and decide to go with one or the other or come up a 3rd alternative (merge) but I’ve never seen that successful before. It always produces something worse than either of the other two alternatives Luigi: What I suggest is the following the request for the authors to adopt the document and if Joel’s agree what we can do is to formulate a call on the mailing list. Just formulate it in in a way that makes that all the participants in the mailing list aware that there has been a recently a different approach from Thank you for the clear presentation. Joel: We need to bring it to the WG. WG needs to be clear what it wants. - LISP Distinguished Name Encoding - https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/ 10 Minutes (Cumulative Time: 70 Minutes) Dino Farinacci Dino presented the draft and saying that it was very useful for troubleshooting, the idea is not new but derived from similar feature in ISIS and OSPF. He addressed the comments on the list by adding use case section with examples. Added also a collision consideration section after Joel had a comment that if there's two different types of distinguished names registered. Will they counter conflict with each other and if they would have to be in separate instance ids just like two routers that are behind NQTs use 192.168.1. Those two things are registered to the same mapping system but they don't collide because they're in separate instance ids. Dino : So, we started the draft in April of 2016 and we're now at um the latest draft that I just submitted a few days ago is 2020. So, this very simple seven page draft has been going on now for four years. Comes to a point where you have to ask why is the progress been so slow. There is utility, there has been some support. There has been commentary over the course of the six years and there's really has been no strong objections so I’m wondering why. Joel: I have to disagree with that once. I went and looked carefully at this I do have strong objections what is in here are not distinguished names and as I've said on the list the solutions you've proposed are not good enough. This is a “I can just dump an arbitrary string in and well it'll work with my use cases and as long as everybody's careful it'll work but I can't tell you exactly how to be careful”. Other protocols that have done this have gotten into big trouble and he really doesn’t want LISP going down this path. Dino: well I have no reply to that I don't know what your definition of a distinguished name is but I’m using that term because it's assigned to afi 17. What it is an ascii encoding which or can be a unique Unicode encoding if we use a different AFI but it's just a it's just a string and you know it's no different than a DNS name where you have to coordinate what the value is. Joel: The DNS names are structured. Yes, they are distinguished these things are not distinguished they're just arbitrary . Dino: Not calling them distinguished. Saying that the AFI is distinguished on the particular use case they have to have structure. The ECDSA draft shows an encoding where you do not have collisions and it's as simple as that. If you think another use of it's going to collide with that specification you don't run it in the same instance id so these are very solvable problems so don't know what the objection is. Joel: No, they are not. Fundamentally you're expecting everybody to magically go over and use it without going to finding how to distinguish it. Dino: Those drafts specify how the names are supposed to be encoded. Read the drafts and give me specific comments please rather than I don't like it because it's been done that way before Joel: You’re missing my point. The usage draft specifies how to encode it but the draft doesn't specify what the requirements are that must be met so that things are distinguishable so that different uses don't collide. Just saying don't think they might collide into different instance ids is not going to work for writing other specs. It requires magic knowledge. Dino: It does work Joel, I don't know what the problem is they won't collide if they stay separate. Why do RFC 1918 addresses not collide? Joel: That's a big problem Dino: The system works because we keep them separated because we have virtualized networks that's how it works. Dino: Third attempt at least to request at least the working group draft. Had support few months ago, but chairs thought otherwise and then Joel objected to it. Luigi: I have to disagree as well. Let me try to explain my concerns -the document has not been really evaluated by the group. You had once presented the document then you had several updates etc. What happened is that you moved forward the document at some point and said it's time for the working loop to adopt this document. Dino: Clarified that he never said so that he is requesting the working group to consider it as a working group document. Luigi: yeah okay fair enough. Dino: If we make a working group document more people will review it. Appreciate the comments Luigi: The point is to become working group document, there must be some interest people have to see the interest in the document and say I need this. What happened on the mailing list was more about “yes why not” Dino: Type of support? there was support on the list people said it should be a working group document. For some reason, the chairs are deciding to ignore that. Luigi: no no that's not fair, trying to see what is happening. There are some concerns about development. What I suggest is that you and Joel really try to discuss what are the concerns and what are the technical issues concerning the this document okay and then we go back to the mailing list and the working group. These are the issues that Joel had and does anybody has concerns and are people really interested in having these in lisp because you think whether this is a feature that is needed or not. It works for you when you are alone in your implementation something that has to work with the Internet and the LISP as a whole that's my point. If we reach this level of specification because in my opinion the documents I told you this on the mailing list is under specified. There are missing pieces that maybe they are clear to you but are not written there. Dino: okay so I would like to receive specific comments please rather than just making a high-level problem. Luigi: Said he will send specific comments. The point is to check if the working group should consider adopting this document. It's about the interest how useful is for the least I understand from your perspective it is very useful but it's about the working group. Dino: We have other implementations of it too, not the only one using an implementation so. Luigi: Maybe I'm missing something and we will work in the coming weeks to clarify everything. But Joel has strong concerns. We work on this and then we move on we check what the working group thinks. Fabio: I just wanted to make a short comment. Looks like Joel has some specific objection right probably it seems that the word might help from him articulating better what are the objections. The suggestion that Luigi's giving is spend some time with Joel. The two of you sit down and you try to basically understand what Joel is saying and Joel is trying to articulate in more detail. That will eventually lead to having more content for your document so I don't see how that is detrimental. Dino: Right we have started that process and we had one round. The document was written and Joel's not satisfied so we have to do it again so that's all there's to it. Fabio: That's how it works right sometimes Luigi: Then we will check if the working group is interested in this work I hear your voice you say it is but we have to check it as for the usual process okay. Is it okay for everybody if we proceed in this way does anybody has further comments? I invite you all of the people to read anyway the document and beside the technical concerns that you may or may not have make up your mind if whether or not this is something useful for this and the working group Dino: Mentioned that there was several supports on the mailing list. Luigi: Mentioned that nobody said that nobody is interested. Rather we were not able to declare a strong consensus and there were technical concerns about your document. We can work on the technical concerns and make a full normal checking whether or not the working group is interested or not. - SD-Access: Practical Experiences in Designing and Deploying Software Defined Enterprise Networks - https://arxiv.org/abs/2010.15236 30 Minutes (Cumulative Time: 100 Minutes) Jordi Paillissé Alberto: Jordy has done a great summary of the paper in the presentation but the actual paper that is available on that link. Luigi: You seem to rely quite a bit on the MAC address. That works very well in enterprise networks but if you have a public deployment let's say a huge campus that wants to get Wi-Fi connectivity now maybe you will connect to user in iOS or Android and I discovered this week that they have features to change dynamically the mac address because of privacy concerns. Maybe you don't have an answer now but have you thought how ? Can you comment how would work if there is this thing of dynamically changing the mac address? Jordi: Well that's really good question I should probably think about it because I couldn't attend the BOF yesterday and also because I’m not very savvy in the implementation. We have Mark here that can comment more on the implementation but so lisp is just something on top of all the layer 2. I really don't know how it would solve it but I think it's a problem that everyone would have also still because it's not LISP specific; Joel: no no it's not LISP specific but for those who are tracking the missing pieces this there was a BOF called MADINAS yesterday driven by a bunch of work over at IEEE on randomizing mac addresses periodically changing MAC addresses and what that does for IP activities which depend on MAC addresses . Mark: actually we have started discussing how to address this problem in the with the sda solution there are and this was explained yesterday in that BOF there are multiple approaches to randomization of MAC. I would say that thanks to the way that LISP works multiple of those use cases could still be handled well the most extreme one though I think it's the one that Apple has implemented in some of the latest Ios where when they really randomize or they really generate the different MAC address every time they change access point and this is the one that we are studying now but there is this mode in sda where you can work L3 only and just use IP addresses as identifiers that could be one possible first approach but still yeah some work to be done. As you say right it's affecting everybody right not just at LISP - Overflow Time/ Discussion 20 Minutes (Cumulative Time: 120 Minutes) Dino: Are RFC numbers soon to be assigned to the bis document? Joel: we are hoping we will go in soon but it depends on the RFC editor queue. And we do not get to tell them what is the priority. Dino: if we could still write documents and reference the rfc doc # Joel: says that we are not supposed to use these numbers as they can change. Sharon: that is where I want to be careful. That paper to go to ITU but we cannot. Joel: We all want it to be done but we need to do things in order