IETF 106 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) =-=-=-=-=-=-=-=-=- Tuesday, November 19, 2019 10:00 - 12:00, Morning Session I, 120 Minutes Room: Hullet - Administration Halpern/Iannone - Blue Sheets - Agenda Bashing - Status reports for WG drafts 5 Minutes (Cumulative Time: 5 Minutes) Luigi: Commented on moving the RFC 7954 and RFC 7955 to Historic Status. RFC 7954 was asking IANA for specific prefix ipv6 prefix to be used experimentally for Lisp. RFC 7955 was the guidelines on how to manage this block. So far RIPE has very kindly take over on the management of this block. The experiment went over for three years and the deal was if we don't have sufficient demand for the traffic's blocks and there is no specific action from the IETF then we give this block back to IANA. We had few requests about an EID prefix but there was no specific action so it's time to give back this block to IANA that happened in September. The most reasonable thing to do is to make them historic and we can add the note that you can see to the two documents. Padma: We actually have the Anonymous EID draft that was actually using a portion of these prefix blocks. We'll need to find out what we're going to do next. Of course it is possible to ask for another range or change the range but I wanted to let you know that . Luigi: From my perspective, there are two way forward for this document. One, do you really need an allocation of IANA and in this case you may ask one in the document itself. Otherwise you just can specify the fact that maybe an operator should reserve a prefix to use it for the Anonymous EID. Padma: The advantage of having an IANA pool is that all operators may use that and you have a better anonymity. If you have each operator giving you a pool then you won't have an Anonymity that is as efficient. Dino: The reason we needed a well-known allocation is because if we wanted the rest of the bits of the address to be a hash of the public key and we wanted an application to use that to look up a public key to verify signatures. It would be nice to know that it's not an opaque address or an address that's assigned a different way but it actually is a hash. Luigi: The only comment that I can say okay but not with these prefix. It is too late. Padma: I think we're fine with that this is noted. o 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 20 Minutes (Cumulative Time: 25 Minutes) Albert Cabellos Fabio: Thank you Albert for taking care of the comments because it was a massive work. All the comments were incorporated in the discuss in one of the last review we got. Luigi: Acknowledging Albert's work, solving comments and discuss was a huge work. Deborah: I also thank you for your work and I encourage you try this week to get with Mirja and Benjamin to encourage them to look at this because what will happen in two weeks everybody will take start taking the Christmas holidays New York holidays. Especially the europeans go skiing and Mirja will not be on the IESG next year. So we got to get this done so I really encourage it to these next week two weeks get them busy with them. - LISP Generic Protocol Encapsulation (LISP-GPE) - https://tools.ietf.org/html/draft-ietf-lisp-gpe-11 20 Minutes (Cumulative Time: 45 Minutes) Fabio Maino Luigi: Just a quick note on GPE. This document past WGLC a while ago and was under review at IESG. There were a few comments and changes that we believe are important, so the working group has to be aware of them. It's just an update but we do not need to go through again through the same process,. Joel: I understand we don't have transit nodes, the closest we have is an RTR. RTRs technically terminate a tunnel and start a new tunnel. We don't have any transit nodes. I've noticed this coming up in a number of overlay protocols where the protocol runs between two endpoints and somebody starts worrying about what is the transit node doing . Let's not make any argument about transit behavior. Dino: Your comment is very right about our RTRs. But, there could be nested headers? Fabio: Maybe we should write more clearly that and I agree with your reference on fancy notes. Maybe what we should specify is that at the tunnel endpoint the implementation can pass in H/W, for those headers that were not defined at the time that the hardware was designed, the packet can then be processed in software. Joel: In terms of ETRs is just fine, just the transit header caught my attention. Fabio: That's a good comment. I'll change according to what we discussed. Luigi: It would it be enough just to drop the transit word and say this GPE node. Fabio: Yes. F abio requested review and comments to be sent. Luigi: Comment on slide. These are controlled environment and they are connected over the public Internet still connecting controlled domains, so if the domains are controlled. You have a way to know who's using GPE. Fabio: It makes sense. That's a good comment. After changes the document will be sent for review for last call. o Non WG Items - LISP Uberlays - https://tools.ietf.org/html/draft-moreno-lisp-uberlay-01 15 Minutes (Cumulative Time: 60 Minutes) Marc Portoles Comeras Dino: If somebody happened in a side uberlay one point to a Map-Server in the core Uberlay (and it's against the requirements of the draft) maybe the site ID that's being registered could actually be known in the core Uberlay and when it registers to overlay one it can do the loop detection. You might be able to prevent this dynamically without any special, anything other than what you've already specified. Marc: We could actually use it but I think we could still find cases where we may be able to break it . Dino: Clearly the draft says you shouldn't do this and if somebody accidentally does it, does the machinery actually keep the network together? Joel: It's not the machinery. It isn't going to take care of the horizontal links. They need the rules anyway. Luigi: For clarification, does the site ID comes from the site from which I learned the mapping or from the site publishing the mapping? Marc: It identifies the origin but it's meaningful in the destination. It's a number that both border XTRs redristributing the EIDs need to share in order to be able to implement this. Joel: So it's more than just locally significant to the site. Marc: Actually it does not need to cross side boundaries. We have the border set, these two guys are connecting these two overlays. Let's say the overlay on the side will use a site ID to identify that prefixes come from side overlay. But this number is only significant for the two borders and it must be unique in the overlay but does not need to be globally unique. The site overlay does not need to know anything about this number, which is used by these two borders in order to identity, to recognize, registrations that they have made and they have come back to the same border set. Joel: So it's used by the borders in case their registrations get reflected from somewhere else. It's carried opaquely. There is a requirement than in order to make it work different sites better manage to nonetheless use different ones even though they're locally significant. If two sites collide a misinterpretation will happen, so it's not quite locally significant it's a 64 bit number that's a random. Need to be careful how you describe these things. Dino: To me it's a little bit misleading, how you have the things going. Because what's happening is the XTRs and b-xTRs are registering to MS1. So what is the arrow going from MS2 back to B-xTR2? Is that a message? Marc: It could be a publish message, for example so the border XTR does subscribe to receive everything that is resisted on Map-Server 2 . Dino: Are you saying Map-Server 2 is sending a Map-Notify message to XTR2, telling them about things that have been registered to it which could have came from other site overlays but could also come from itself and therefore you know you shouldn't register it. Marc: We could also have partitioning or any sequence of events that can lead to this. Dino: If Map-Reply has an RLOC set in it, by definition it's not a negative mapping. We should use the right terminology . Luigi: May be use the term proxy. Dino: Anybody who sends a Map-Reply that are not their own RLOC are advertising RLOCs of somebody else and yes you can call that a proxy. It's a great term because when Map-Server returns on Map-Reply on behalf of an ETR it's a proxy Map-Reply by definition. - ISP Mobile Node Multicast - Demo 15 Minutes (Cumulative Time: 75 Minutes) Dino Farinacci gave a multicast demo with lisp mobile node. Victor: If a receiver is multi-homed do you have to provision? Dino: iPhones (I don't know about Android devices) they have multiple connections but they only use one at a time. Joel: That is one of the thing that are working to change. Dino : In iOS or in general? Joel: In general. We don't know what the implementations do. There are talks about using multiple interfaces, and it may be transparent to you. There is definite support for even splitting but simultaneously Wi-Fi and 5G, so this is something they're all looking at, but it's all ongoing . Dino: I would argue that if the IGMP was report was being sent to an EID of the RTR then the ITR can see there's two RLOCs for this EID. Then, I can load split across them so that's how we could do it with an overlay approach. Albert: The problem typically with mobile phones is that although multi-homing might be available at the kernel level, they typically hide this kind of functionality and make it transparent to the application level, which means that it's very hard to take advantage of that. Marc: Could we maybe bring back the control Map-Server into the picture? Dino: I don't know if that helps the problem. If we put a Map-Register functionality on the phone and it registered its EID joining the group, it's not only registering its EID that has two interfaces it's also registering to 224.1.1.1. When it does that, it can put a RLOC set in that register saying I have two interfaces and to the replicator it looks like two different places where in fact it's the same but you'll have to do duplicate detection on the receiving end. I've been getting requests from customers contracts that it's nice to send packets both ways and if we can use the nonce to detect duplicates and have a small cache then on receipt we could drop the duplicate packets. That's subject for another topic, another IETF. Sharon: If you want to fix that for public safety channels, this is not a bug so keep that option . Dino: Ok, Interesting . - Distributed Geo-Spatial LISP Blackboard for Automotive - https://tools.ietf.org/html/draft-barkai-lisp-nexagon-11 15 Minutes (Cumulative Time: 90 Minutes) Sharon Barkai Author asked for WG adoption . Joel: You will need an email to the list from you asking for adoption. Sri: Can you talk a little bit more about the AAA? You talked about the damage interface? The diameter of messages? Sharon: You have IP connectivity and you want to use specific mobility network, what you do is you ask for authorization from the DNS: what is my AAA server for this mobility? You will get an IP address and then you ask a diameter server in which you give it your credentials, user password, vendor, etc... and you will get back an EID which is your overlay address on top of the carrier IP address. It's a v6 overlay address that you're gonna use in an RLOC which is a tunnel you're going to use for the edge. Sri: Before that there's a sim-based authentication? Sharon: No, that's already done by joining the mobile network . Joel: He's authenticating the user of the network; he's authenticating the user of the overlay service . Sri: It is admittedly an unusual use of the AAA protocols, because they're normally used inside the network. It was not clear to me. I like it. Dino: Did you want to run LISP within a slice or across slices? Sharon: Typically the carrier will provision slices of quality of services for our IP network. So in LISP everything is unicast . Dino: Do you have an EID for each slice, in a separate mapping system, or would it be a crop? That's what I'm wondering . Sharon: No the slicing is purely for the EBC. Dino: Looking at hexagon tiles, where you have one bigger hexagon covering 7 smaller hexagons, should the small hexagon in the center join one multicast group plus the multicast groups of all its neighnoring tiles? Or should it joint the group that is the aggregate of all of them? I've noticed with the resolutions they don't map exactly and fit exactly so do you have to join seven groups the one you're in and all the six neighbors? Have you thought about any of those how to make work ? Sharon: What you use is a specific resolution for multicast, which is resolution 9, which is like a few blocks. Let's say this Ruffle City holds all the tiles that's EID addressable. When you have hierarchy there is leftovers, this is the price you pay for having a polygon which is both approximation of a circle but ties in an hierarchy. In R9, there will be some overlaps, but what you will do is that because you know where you are you will register for the tiles which you are in your direction vector . It's a joint latency data and state trade-off and we you now see it showing early. Joel: If you know where you're going you join beforehand. Sharon: Exactly. Dino: But if you join to a larger grid then you don't have to leave/join, packets will go to more places. Sharon: It is similar to handover. You may join a few just to make sure that you are covered. For the same reason, it's okay to receive multi-home, it's all contained so you just get more. It will just receive a look ahead . Dino: It depends how soon you start joining, because there is join latency. The join message is like Map-Registers, UDP messages that can be dropped. Will you get the information soon enough? Do you have to plan multiple tiles ahead of you? The code doesn't know that the driver is gonna make a right-hand turn right .... Sharon: No, but the client does know it's vector and the driving. Joel: There's a distinction between useful to know and really promptly and safety-critical information. As far as I know you're not trying to handle safety critical data. Really fast is a different scale. - Overflow Time/ Discussion 30 Minutes (Cumulative Time: 120 Minutes) No additional discussion took place.