LISP WG IETF 101 Monday, March 18, 2018 13:30 - 15:30, Afternoon Session I, 120 Minutes Room: Palace C - Agenda Bashing WG Updates and Presentation of Agenda by Luigi and Joel Comments: Albert: Does it makes sense to list the bis documents in the intro? Luigi: The new bis documents? Not sure how much you can do, this doc in RFC editor queue and missing a single reference. Dino: Question about the bis documents? There was no mention about the LISP-Sec document and that seems to be the only reference document that the introduction document is waiting on. Luigi: We discussed this already last time we took the document back. The basic idea is we switch it to standard track but we need to make sure it is coherent with the bis documents. LISP-Sec will reference the bis documents. My point of view if we did a good job. We just proof read the bis documents and then LISP-Sec will be pushed right behind. Dino: Do you think the bis doc will move fast? Luigi: Depends. The IESG may be overloaded. Joel: Changing a reference in a doc means pulling a text which means the doc has to go back to working group last call, ietf last call, iesg approval ? it is the procedure. - WG Items Presentations - Update on LISP 6830bis & 6833bis & OAM draft-ietf-lisp-6830bis draft-ietf-lisp-6833bis Dino Farinacci & Albert Cabellos Albert: Presented that the 6830bis draft that went through 5 iterations since IETF100 meeting. Then went over the different changes. 6833bis went through 3 iterations. Discussion on 6830bis section on Mobility, Deployment and Traceroute considerations removal and to be placed in a new OAM document. Luigi: Have a quick question about the OAM document, when do you plan to do it? Dino: Are you going to push the OAM document at the same time as the bis documents? Will it not slow these down? Luigi: No, it will not. OAM text did not go raise technical discussion but it needs to go through the whole process. Albert: Agreed then we need to work on OAM document. Luigi: If we agree the bis doc are ready we can last call these 2. But for OAM we need to have a call for adoption. Discussion on extracting the OAM portion. Albert: It is difficult to extract the OAM section. If we remove the consideration sec and it will be out of context. Luigi: For me it is quite simple, just add an introduction that says LISP data plane is defined in 6830bis and control plane 6833bis. All the administration and management is in this document. The reader is supposed to be familiar with the other docs. Albert: Then I have a problem regarding the reader considering the title. If I have a LISP OAM document, I expect to have the whole spectrum of what it means for operation and management of LISP. Then I find the three sections very narrow regarding 3 different aspects. We can do that but then the title should not be OAM. Dino: I agree with Albert 100% and it is hard to decide whether these sections are really OAM or not. Traceroute probably yes bit putting the mobility section there is totally counter intuitive. I would suggest to put the mobility section back in the dataplane document as it is a general problem. Luigi: If I want to look up mobility I would never go look in a data plane document. Dino: If you want a general mobility description, you will not look into the OAM document but may be in the introduction document. Makes more sense in the data plane document because it is about XTR that?s moving around and it is a general discussion that it sets up for LISP mobile node and EID mobility. Joel: Wonder whether we need the text at all ? If you are just laying groundwork for the actual mobile solutions, is it actually providing any change in the normative behavior? Dino: It is setting expectations of what mobility is. Joel: You do not have to set expectations of what mobility may be handled by LISP. Dino: People should read the section before making this decision because there was a lot of thought put into that text and we should not lose it. People have different expectations of what is mobility is changing. For example, for ISP mobility is an event that happens may be once a year versus being in a high- speed train and changing your RLOCs, so people need to know that LISP is trying to solve the train problem and like the multihoming document is trying to solve a ISP problem. Luigi: I agree but no one wants to lose the text. May be there is no perfect solution but I would not put mobility in the data plane document. I am not shocked using OAM in the title. Let me think about it. Dino: We should ask the working group about the title. Luigi: Sure Fabio: Proposal for title LISP deployment consideration, mobility, OAM. Albert: If we agree on change of title I volunteer to write that. Luigi will send email to mailing list and that there are concerns about title and have a decision by the end of the week. - LISP Generic Protocol Extension - draft-ietf-lisp-gpe-01.txt 5 minutes (Cumulative Time: 25 Minutes) Fabio Maino / Alberto Rodriguez-Natal Fabio: Mostly editorial changes and one technical comment in section 4 on Backward compatibility. Will apply the same logic as the LISP Crypto draft. Next steps are to allocate the new g-bit and update the IANA consideration sections and propose for last call. Discussion about the language to describe the backward compatibility section 4. Luigi: Clarification question .. with this ?g? bit now you have way to find out whether there is support or not of GPE. Assuming there is no support like in legacy LISP how do you deal with nonce and versioning? Do you want to keep it the way it is? Fabio: Yes. Dino: If the encapsulation types returned by the ETR are all the data planes supported by it all those bits will be set. So you do not have to say if the g bit is not set and if that encapsulation type comes from any other data planes you don?t have to say use the default. The only time you have to use the default is when 6830 is LCAF is not returned and you have no information about any dataplane except the default. Joel: Or presumably when there is no match between each point. Dino: Good points we may be check if the text covers that. Should we take an inventory of all the popular data-planes. Fabio: Each individual draft proposing a different dataplane will have to take care of this one GPE is doing that. There is an ILA draft and may be it should do that Dino: I am wondering we need to change the LCAF documents and may be we want to change it only once. Each use case go and ask for a bit and do we need to keep there and the LCAF document does not specify the bit. Luigi: Suggest every document request the bits and we must make sure there is no conflict. Document is small. Ask the room to hum on readiness of the document? Room : Agree that the document is ready for last call. - LISP YANG Model - draft-ietf-lisp-yang-07.txt Reshad Rahman / Alberto Rodriguez-Natal Reshad: Minor changes to comply to rfc7087bis draft Present the changes in the next revision. - LISP Vendor Specific LCAF - draft-ietf-lisp-vendor-lcaf-01.txt Fabio Maino / Alberto Rodriguez-Natal Alberto: Request to move to last call. Luigi: Comments per his review ? 3 editorial comments and no technical comments before requesting last call. Asked room to hum Room: Agreed ? consensus to move to last call o Non WG Items - Publish/Subscribe Functionality for LISP - draft-rodrigueznatal-lisp-pubsub- 01.txt 5 minutes (Cumulative Time: 40 Minutes) Fabio Maino / Alberto Rodriguez-Natal Alberto: Request for a wg doc. Fabio: This draft is driving the other features Luigi: Ask the room for hum ? positive for moving to wg doc - MS-originated SMRs - draft-rodrigueznatal-lisp-ms-smr-04.txt 10 minutes (Cumulative Time: 65 Minutes) Alberto Rodriguez-Natal Alberto: Request for move to Informational status Authors request advice on what is the best way to move forward. Luigi: One possibility, push it as an individual solution. Dino: Does the document suggest that this is an experiment and suggest to use pub-sub. Alberto: We can add that. Joel: There are some implicit assumptions in the draft that need to be explicit and some other things addressed. The WG can consider to publish this as in informational RFC once those are fixed - LISP control-plane for Identifier Locator Addressing (ILA) - draft-rodrigueznatal- ila-lisp-00.txt 15 minutes (Cumulative Time: 55 Minutes) Fabio Maino / Alberto Rodriguez-Natal Alberto: LISP can be used as control plane on a ILA dataplane without changes in ILA or LISP. Tom: On TCP vs UDP, I am not familiar how that works with LISP. When using UDP is there some sort of state that says which Map-Server might send you a Map-Notify. Do you accept any Map-Notify there should be some sort of security right? With TCP you just have connections open to map servers I wish to us. Dino: Tom has a requirement to run ILAMP to run TLS over TCP. To care about a mapping therefore any map server can give you a map notify. A map notify is sent with unique nonce but there is no authentication of it right now. We can extend the ECDC draft to say that Map-Notify can be signed and receiver can verify the Map-Notify with the public key. Tom: So UDP is the predominant use case today or TCP? Albert: Depends on use case. Tom: For ILA redirects there is a need for security and TCP has that benefit. Also upping the whole control plane like a data center type of API controlled protocol as opposed to a low level routing protocol. Concerned about the security. Alberto: good feedback. Dino: For the WG, if we have rest interfaces does the WG have to specify how the API is used? Has nothing to do with IETF and not sure if IETF gets involved in defining those. Tom: LISP control plane fairly complete if we could get that over rest that would be quite helpful. Alberto: Today we have both TCP and UCP in deployment scenarios. ??: what is the driver for TCP? Was the size of the mapping, if the mapping is big rather than having many UDP requests, TCP makes it a bit more reliable. Tom: Been looking at the size of LISP mapping maybe we can compress that a bit. Kalyani: My comments are relating to the mapping system in the 5G system. 3gpp is working on APIs. If the mapping system need to be used in the 5G system, the frame would be introducing in 3GPP. Fabio: Following up on what kalyani is saying this will be discussed in DMM. There should be one control plane and multiple data plane and this is the reason for this draft. Reshad: Isn?t the issue that you have netconf and restconf and you have a yang model which is standardized. The job is done or do you need anything more? Padma: Follow up on what kalyani mentioned earlier on the placement of the mapping system in the 5G system. I would encourage you guys to look at the document we have published in another SDO that actually explains very clearly all the interactions between the 5G architecture functions with the mapping system. I want to discuss with all of you guys so that this work can be leveraged. It would be good to reference it here. Luigi: Why don?t you send a pointer on the mailing list where we can find the document. Padma: Sure Tom: On applicability, I agree it would be nice to have one mapping system that could cover all use cases. One thing though if we are using a mapping system within a closed network vs a public mobile network, privacy and security is very different I think I raised this issue on the list. Especially denial of service is a tricky one. We know whenever we need to cache, most mapping systems will be a target. These are the things to consider for the broad use case. Alberto: This is something we are aware and actively looking into ad we have discussed different options. Albert: Concerning DDOS attack to the control plane, we have worked on solutions in the past for that and we are planning to release a document explaining how we can solve that. You will see all the details but to me the main point is that these types of infrastructure are very common and many solutions around. Dino: Since you may subscribe to info that spread across thousands of map servers they don?t need to send you a notification themselves each time a notification change. At that time if you have a TCP connection established you have a 3-way handshake, otherwise delay will cause convergence problems. Because that means that every map server has TCP connections to everybody together in the internet that is not a scalable solution even though large DC have thousand of TCP connections ? this is a different order of magnitude. - Ground-Based LISP for the Aeronautical Telecommunications Network - draft- haindl-lisp-gb-atn-00.txt Reshad Rahman / Victor Moreno Reshad: Update on the ICAO meeting. Main difference found by evaluation was there is an initial packet loss with lisp and there was none with AERO. Fabio: Initial packet loss is a well-known behavior in LISP and there are mitigation with use of RTR Luigi: Regarding initial packet loss is something we can avoid. Dino: An implementation can decide to mitigate and if it is important you can make it such that it does not drop. Luigi: Years ago we said that this is implementation. Dino: May be the specs do it but specs don?t. It is not a must we can do something else Erik: I know of an implementation that is not open sourced yet but it does keep a packet for a while. You don?t to keep it forever but it does keep it for a limited time Reshad: from what we know it is not a big throughput so that seems feasible. Luigi: If this is a private network we can choose to keep. The reason we drop is not to fill the buffer of the queuing but if this cannot happen then it is reality safe to save them. Reshad: it is supposed to be a closed network but there are several networks ? American, European? so it not a simple flat network. Victor: I would really encourage the WG to have read and you will find implications of the pub/sub here on regional network on mobility and how you would that best or some proposal on the draft but it is not necessarily using things like DDT so there is a lot of thinking that can go into this. - A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network - draft-templin-atn-bgp-06.txt Fred Templin Main architectural change is the AERO proxy which sits at the datalink sub network border and acts the same as for an enterprise network web proxy so inside the sub network the client airplane interacts with the proxy in the same way it would interact with a server in the outside world. - A Decent LISP Mapping System (LISP-Decent) - draft-farinacci-lisp-decent- 00.txt Dino Farinacci / Colin Cantrell Comments: ??: do you use unicast instead of multicast for the requests? Dino: The problem is if you are in a situation where you have the Internet but you need to auto discovery each because XTRs will be added and deleted. By using unicast there is no way you can auto discover. Usually for discovery we use multicast or directory services and if you use directory services you are depending on a third party. There are solution but you will need to preconfigure. We want this to be like a crypto currency where everything is pretty self- discovering peer to peer. We are basically buying applications from the crypto currency world and trying to apply it here. May look like a routing protocol but it is not because it is over the top.. just multicasting things with efficient distribution. Tom: so when you are talking about multicast you actually talking about really a multicast group. Dino: XTR join Class D addresses or FF::/8 .. so the multicast service model is available for this control plane. Tom: My impression is that multicast may or may not be available in most networks. I work in 2 really large providers networks and I know a lot of provider networks do not have multicast. Dino: If the underlay does not do multicast we can do head end replication. Tom: So why not just sent it to one and let the head end replication do the rest Dino: Because you don?t know who to send it to, the whole point of accessing the mapping system to send you a Map-Register is that I do not know your RLOC. And I need to access the MS to know your RLOC. If unreliable you send them periodically or add a reliable multicast protocol on this Joel: But you start piling complications. I can understand this is a small case or moderately small case of common things which want to use LISP and which are all on a common fabric which supports multicast so that all the scaling properties and benefits work. But as a general mechanism it looks like it will need so many complexities by the time you are done for the general deployment case. Dino: I am not telling it is a general mechanism and I can show you the use cases we are targeting. Joel: But the draft does not tell you the use cases you are talking about. Luigi: How do you discover the multicast group you have to join Dino: That?s configurable. Joel: if you configure that you can configure other things as well. One xTR running all the time and give you its address. Dino: You do not know which xTR is on your side of the partition you might as well statically configure all the RLOC and map cache entries and not even run a MS. But if they move around and change their RLOCs you may have loops. So that?s why you need multicast for the dynamic discovery. Joel: There is no authenticated delegation. You can authenticate participation but you cannot authenticate delegation. Dino: So, you use our EDCSA draft, the instance ID is part of the signature Joel: That is a different approach from authenticated delegation. Luigi: Then you need to know the multicast group to join but also all the public key of everyone who will potentially join. Am I wrong? Dino: You do and the public keys are registered they do not have to be authenticated. Registering a public key is harmless but using it and what you are verifying that signature data is the previous stuff. Luigi: Goes back to the question of scalability of such a mechanism for big deployments it is complex. Albert: On the ?no third-party trust or dependency exist? the way I understand it you actually have full trust right as you are trusting all participants of multicast group. Dino: Exchange of info require some trust but you want to talk to someone who is giving you the mapping but you can verify that with the signatures right? Albert: But how do you verify with a signature? Luigi : For further comments please take it offline - LISP for the Mobile Network - draft-farinacci-lisp-mobile-network-02.txt - Not enough time.