LISP WG Session 1. Administration Halpern/Iannone - Blue Sheets - Agenda Bashing - Status reports for WG drafts 10 Minutes (Cumulative Time: 10 Minutes) 2. WG Items 2.1 Open session on LISP 6830bis & 6833bis draft-ietf-lisp-6830bis draft-ietf-lisp-6833bis (To be extended if needed) 15 Minutes (Cumulative Time: 25 Minutes) Presentation by A. Cabellos draft-ietf-lisp-rfc6830bis Indicate how the instance-ID is 32 bits in control-plane and 24-bits in the data-plane Removed some references to experimentation Added "Security Considerations" (summary of RFC7835) Described LCAF registry in "IANA Considerations" Updated references draft-ietf-lisp-rfc6833bis Removed some references to experimentation Added ACT values: 4: Drop/Policy-Denied 5: Drop/Authenticate on-Failure Removed open-issues and considerations Other editorial changes LISP Control-Plane Assumptions Which features are required by an arbitrary data-plane (other than LISP) using the LISP Control-Plane? - Map-Cache (or similar) - Carry two routable addresses, one in the overlay and another one in the underlay - Mechanism to monitor RLOC reachability - Mechanisms to notify that a mapping is outdated Albert would like to have some discussion on these in data plane. Comments/Questions Fabio Manio: How is the last 2 points are addressed? Fabio asked whether this is part of the dataplane encapsulation Joel: The last 2 points are crucial and today. We cannot ignore these two things or else we will be blackholing traffic. Has some concerns that today there is no documentation on the solution. Fabio: This the right way to put it that if some other DP want to use Lisp CP then they have to be careful about this. Erik Nordmark: Are you thinking about this for l3 over l3 encap are you thinking of other stuff like vxlan as well? Joel: The point is we know people who want to use vxlan for this. You can use LISP as is for carrying L2 traffic. I am not too concerned of the underlining type of packets as this is a property of the tunnel encapsulation. Not fine it not recognizing the issue. Need to check the wording to make sure that this is right. Albert: yes the wording to be corrected. 3. Non WG Items 3.1 LISP TE - draft-farinacci-lisp-te 10 Minutes (Cumulative Time: 35 Minutes) D. Farinacci Dino Asked for this document as a wg doc? Comments/Questions Uma Chunduri: Is there any requirement that the itr knows what the lisp encap is in the middle? Dino: Good question. Assume that there is somebody is putting these mappings in the MS DB with these particular ELPs(Explicit Locator Paths). It could be an eTR, SDN controller or some other management functions. It should just work regardless of number of AS hops because this is an overlay. Victor: Clarification on slide 3. You just put the address in the packet which will be the interface address receiving the packet. So your encapsulated packet goes through the interface to the ETR. Dino: That is the rloc address of the RTR Depends on what address is used in EID. If you use the interface then the packet will arrive accordingly on specific interface. If the loopback address is used then it will comes through whatever interface through routing. Victor: here it is suggesting you are using the router interface. Dino: Really Good question. If x wants to encapsulate to y and y wants to encapsulate to z, what you are saying is what would be the source address be? It could use any address but it certainly could use y as well. May be you should be using y depending if you are trying to do multicast on some security concerns then may be use the address which is in ELP to ensure it is the right guy sending to you. Really good comment. Alberto Rodriguez-Natal: Correction on the number of implementations. There are 3 open sources and 2 different implementations at cisco. Dino: The NXOS one is most mature one in Cisco. So what do you use as source address? Peter Ashwood-Smith: Quick question. Apologize have not read the draft. Can you talk briefly about any source Entropy and source ECMP? Dino: No different from any encapsulated packets. The source get chosen and in the UDP encapsulation. Joel: LISP header always deals with this. LISP encap already use UDP and this is addressed already by LISP basic mechanism. Dino: When a sends encapsulated packet to x and x decaps and reencaps it is almost like label swapping, so it is not really intuitive. It would look like a seamless encapsulation. Take a hash on inner header on the RLOC and UDP. In either case there is an entropy .. RFC6830 talks about reencaps of tunnels which this is and recursive tunnels would allow you to carry carrier stuff. Luigi: Out of curiosity, this is talking about source routing. Dino: Yes, this is an alternative to Spring, just another way of doing it and but it can do multiple AF. Uma: If you want to use to route between these two you can have a dedicated path. D: It would be nice to select and store the rloc in MS and also have a segment route and then control the path in the underlay. There is also similar discussions in the multicast case as well Luigi: No objection in room 3.2 LISP Mobile Node - draft-meyer-lisp-mn-16 10 minutes (Cumulative Time: 60 Minutes) D. Farinacci / D. Meyer Dino: Gave a brief history of LISP. Originally LISP for host, this draft is an opportunity for putting LISP on a mobile node. This puts LISP in the position where it has the architecture for mobility. Dino: Presented Earlier in Buenos Aires. The EID would be fixed and never change but the it would be possible to change the RLOC changes but we still have TCP stay up and have session continuity. Comments/Questions Joel: Careful because of privacy concerns Dino: Technically you are right there is another to have secure communication when you are moving around. Luigi: Even though the document has been there for a while it has not been chartered. Now we have chartered it and will be working on it. Albert Cabellos: There are implementations in progress. Out of experience there are the things that need to worked on in this kind of documents. At the end, many of the challenges come from NAT, for instance it is not specified is what happens when you have an interface behind NAT. What happens when you do not have a map cache, you do not know where to tell the new mapping , when there are multiple interfaces there need to do more work on how to do switchover. There are issues with MS. there are issues regarding multiple interfaces moving and how handover works from one interface to another in these situations. Support the document but we need to try to work on these. Dino: OK Let me response to the NAT question. In the document documents how it is supposed to work across NAT. An XTR always encapsulates to an RTR and so as the node move it is only that RTR that needs to know of its rloc changes, all the other peers were encapsulating to the RTR. In this case, this is a very good scalability feature where you have only a subset of RTR that need to know of the change. This is pretty well speced and documented in the NAT translate draft. Albert: My point is when you have a handover and that you are no longer behind NAT and get a public IP address. You have no longer in the RTR but you have the map cache. This is the case for hetnet cases Dino: OK, this needs to be addressed. Luigi: we need to enhance this document Dino: Not sure it has to be to put this in this document as this is not necessarily a mobile node only problem. Peter A.: Quick Question about the cellular on mobile environment. The various GW are both a source of revenue and cost to operators. They essentially want to get rid of them. What would be the replacement? Do you have some thought and how to it would work in this environment. The discussion before was about that these gateways and that they have a lot of other functions and when we started looking at this and it has about 20 pages of stuff with things like billing, policy and so on. In fact we had this discussion before but wondering if you have thought about this. All of these functions would have to be show that they are no longer need or replaced. I know it is not as exciting as some of the rest of the stuff but have you thought about some of these points. Dino: Padma wants to respond to this question. Padma Pillay-Esnault: As you know, the 5g architecture is still being discussed right now and no one knows for sure what is going to be the next architecture. I think may be your question is specifically about GTP and the services around GTP, because that is where we really have pages of stuff. The handover of tunnels. Peter: The question was not so much about the tunneling and this is a just a mechanism. There are intermediate things that do things like billing and policy Padma: I agree. I don't think LISP currently is or should be addressing those. Peter: This is why precisely why I am asking this question. Padma: But I think we are talking about two different things here: the control plane and the data plane. The control plane such as billing and policy GTP even thought it was clumped and tightly coupled with the tunnels signaling and data forwarding in the past .. do not have to be so in the future architecture. Dino: Are you saying that this should remain as is or is there a way to put charging and billing in the database? Padma: This is precisely what IDEAS is looking at. Peter: If I can break it down a little bit, you can do the billing in those GW, you can somehow accumulate billing and put it in the DB, or using the mobile devices themselves. There is a lot of work about the mobile being the ultimate anchor point and have the being billing there. Dino: We can do make LISP run in the UE. One way to look at this as but we have also possibility to have the enb to do the encapsulating. If we use the separate EID and RLOC encapsulating capability , then we can have the enb doing some of the encapsulation. But when we go to 3gpp they may ask whether we are replacing tunnel to another type of tunnel. Peter: There is a beauty to have a mobile device to another mobile device to have the absolutely shortest path. For low latency application people are looking at this. Dino: So you are saying encapsulating ue to ue would be a nice feature. The radio signals still need to go to the enb, this is something to think about. If you want to attack the cellular network then you need to show that you are providing some benefits for all the other things you are losing. Padma: Comment regarding the UE to UE, let's not forget we are still going over the air interface and we will have big headers. So there are pros and cons to that as well. Another of looking at it, is how should we place the mapping and what does it take to have really efficient mapping for this type of situation. Uma: I was looking in the mobility draft. Is there any bearing on ipv4/ipv6 here? Dino: The UE could have ipv6 and ipv4 address and it even though the example was with ipv6 address it can be anything Uma: What is the latency? Caches to be updated. Do you have some numbers HO 4g to wifi? About the caches to be updated and look ups. Dino: That kind of a long answers and there are many ways of doing these so will take offline as long discussions. Albert: I would not say that all latencies are very much LISP related. You need to update the mapping which is very fast. There are many steps and this can also be also about other sources such as wifi authentication introduces also latency. Uma: I see that. Dino: So we know when you move from one place to another, it may take much longer depending on the signaling. We have a proposal that Padma is presenting called Predictive Rlocs. And we think that is a solution for zero packet loss. Uma: The questions is when you are talking about mobile to mobile, we need to resolve the PGW to PGW which is not solved in 4g. The problem is that you need to register to this new PGW and this problem is orthogonal to LISP. This new authentication to PGW will also contribute to latency. Dino: Understood. Padma: Just a comment in regards to what Albert said earlier comments. We should look at latency across multiple functionalities and have an idea about how they contribute to latency. It is important to understand how the latency is spread end to end. This is also another aspect regarding how we cache and where, how we actually log in. This is very interesting and we need to invest time in study of all these aspects. Dino: You can actually put all this in a slice in instance. Padma: The PGW mobility problem can be solved with Predictive Rlocs but it does take some timing to ensure that this is most optimal. Luigi: This is an interesting discussion but you can have make before break solution and solve the registration problem. Padma: The problem with make before break is then reforwarding is that with new applications with are very sensitive to latency and now may have issues when the reforwarding is long and signaling is added on top of that. Luigi: This is an excellent discussion. We will charter the doc and poll to adopt this document as a wg. No objections in the room. Poll the room whether it is not suitable to charter mobility as part of the charter. Silence in room Will add to the charter. 3.3 LISP EID Mobility - draft-portoles-lisp-eid-mobility-01 5 minutes (Cumulative Time: 50 Minutes) V. Moreno Victor: Presented earlier in Buenos Aires. The differentiation from the presentation that Dino made earlier is that that RLOCs are not on the node itself. The RLOCs exist on a different infrastructure than the endpoint. Ask for this document to be considered as a wg document. Comments/Questions Uma Chunduri: I can see how these two (drafts) is tightly coupled, in mobile cases EID and RLOCs are both changing. Can you please explain the reason why you separated those two? Victor: There is a history and some implications. There are cases with applications specially in NV02. Uma: Is there any special considerations on the EID on what it should be for example? Victor: Definition of EID or use? The definition is specified in the draft. Peter A.: My question is in the interest. I am aware of in IPR to replace distribution hash tables. The company went bankrupt and bought up by somebody else. Just make a note that I made a comment. I have sat in court before for not saying something like this. Luigi: Clarification? You use EID to distinguish between L2 and L3. Victor: We segment the mappings with l2 or l3. Dino: When you do l2 overlays vs l3 overlay there are complications because an L2 overlay it makes the box look like a bridge but when you have an l3 overlay it looks like a router. So when a packet comes on an interface you do not know whether you should take the mac frame and bridge over the overlay or look at the ip hdr and make it an L3 overlay. So what we are trying to say we should look at the interface whether it is associated to an Instance ID, a vrf or an IID which a 1x1 mapping. The behavior should be determined by the ingress interface whether we bridge or route. Joel: This is not how things have been done in the past when having combined bridging and routing. Dino: That is because we failed. Joel: There are a lot of bridges and routers who work just fine today. It bridges over whatever is its bridge domain. Dino: It is not that simple. Because this works only if you respond only your arp requests but if the arp request is for the host and we have to figure out how to respond. ... So you have to determine how this interface is going to answer arp requests. Joel: It is pretty straight forward. Victor: It is more a matter of bridge domain vs routing. Gave an example. Luigi: How long has it been since this document.. Victor: The document has been around 6-9 months. Dino: This is a merge of 3 documents Fabio Maino: I do not remember all the other documents but we had l2 mobility, Mobility and added to this document and let the others go. Luigi: query for adoption several people read the draft and no objection in room 3.4 LISP Virtual Private Networks and Extranets - draft-moreno-lisp-vpn-00 10 Minutes V. Moreno Presentation and Request for adoption as wg document Questions/Comments Reshad Rahman: We discussed about this Victor. In the next version, are you going to put some text where the same EID segment can you multiple rloc. Or is it out of scope? There is an assumption that multiple id segments use different rloc segments. Each EID segment would be using only 1 Rloc segment. Victor: Yes Agree. Victor: Request for adoption Luigi: poll for adoption. No objection will take to the list Joel: This is not changing LISP but the access policy using LISP mechanism Dino: The exact change is that the rloc record now has to be an unified list where it stores the Rloc and Instance ID of the path. That is what we speced out. Joel: OK. Dino: We used an exist LCAF which is LISP LCAF. Joel: Important that in this case that the receiver knows what to do with the list it receives. 3.5 LISP A Blockchain-based Mapping System - 20 Minutes (Cumulative Time: 80 Minutes) A. Cabellos Albert: Presented in IDEAS side meeting also Brief tutorial of block chain Comments/Questions Joel: How does the MR know which MS? Albert: Assumption that the information is distributed everywhere Joel: This is a lot of data 93:00 Erik Nordmark: But this is storing the delegations and not the mappings. The number of entries might be large but it does not change that much. Albert: Yes. If you think that your mapping will be changed very often then you should not be using blockchain to put it in the mapping system. Dino: Real quick question this is not trying to support ddt. It is not trying to do map referral like ddt Albert :yes Albert: you can think of 30 participants but if only 10 participants.. Joel: does all participant need to interaction with the MS Albert: Dino But you still need a MS to forward to. Prefer the referrals, the referrals only happen at the time of the building the ddt structure Albert show Dino: The blockchain lookup concern. Albert on need to do the whole list to verify that all is fine Context Albert it provides more info that we actually need - LISP Beta Network 10 Minutes (Cumulative Time: 90 Minutes) A. Cabellos Presentation of lisp beta network Albert : Invite people to join Comments/Questions: 3.6 LISP Predictive RLOCs - draft-farinacci-lisp-predictive-rlocs-01 5 Minutes (Cumulative Time: 95 Minutes) P. Pillay-Esnault Padma: Presented in Berlin last year and refreshed in November. This is complementary to the two mobility drafts. We find that in the mobility space that ID solutions are attractive specially to solve issues with session continuity. One of the problem is that inflight packets need to be reforward and today there are many ways of solving that such as reforwarding after storing and buffering. However, it is not very applicable for Heterogeneous networks or changing of providers for example. Comments/Questions Peter Ashwood: The concept of cloud RAN would be very interesting and have control of multiple antennas. Sending a copy to the next rloc is natural. It is very interesting concept to be applied to this application. Chris Seal (Hutchison): It is difficult to be predictable. In theory, it should be predictable but in practice this is very difficult to predict. Padma: Actually it is an interesting question. If you look how we do a handover in cellular networks, the network knows before you where you will be relocated as the target Enb has to accept the HO before it signals the UE. Chris: UE knows because it has been told. While the trend may be predictable. Padma: Exactly, the UE has a list of possible connections it can connect to. Chris: The reason why I am saying is that it is remarkably difficult to predict exactly which sites to go next. Padma: Remember that the UE does have the list of possible connections with their characteristics such as signal strength and so on. The choices are narrowed down and we can work from those. 3.7 LISP EID Anonymity - draft-farinacci-lisp-eid-anonymity-00 5 Minutes (Cumulative Time: 100 Minutes) P. Pillay-Esnault No time. Will be presented in next IETF