CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Terry Manderson ( Terry.Manderson AT icann.org ) SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) Luigi Iannone ( ggx AT gigix.net ) MONDAY, March 03, 2014 1520-1620, Session 1 (of 2). 60 Mins ================================================= Note Takers: Luigi Iannone, Wassim Haddad, and Damien Saucez Note Well! Agenda bashing http://www.ietf.org/proceedings/89/agenda/agenda-89-lisp Chairs' Slides http://www.ietf.org/proceedings/89/slides/slides-89-lisp-8.pptx ================================================= Joel Halpern => Not much progress on LISP Introduction (http://tools.ietf.org/html/draft-ietf-lisp-introduction-03). We will deal with that right after this meeting. Joel Halpern => LISP Deployment Consideration (http://tools.ietf.org/html/draft-ietf-lisp-deployment-12) is done and is in the RFC Editor queue. No Agenda Change Proposed. ================================================= draft-ietf-lisp-threats (Damien Saucez) Document: http://tools.ietf.org/html/draft-ietf-lisp-threats-08 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-7.pdf ================================================= Damien Saucez => (end of presentation) Do folks think we are ready for WG LC? Terry Manderson => (to the room) Let's check the consensus on this question. If ready for WG LC please hum now. [Consistent number of people humming] Terry Manderson => Please hum if you believe this document is NOT ready for WG LC. [nobody humming in the room] Terry Manderson => Thanks, we will take it to the ML. draft-ietf-lisp-eid-block (Luigi Iannone) Document: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-08 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-0.pdf ================================================= Luigi Iannone => Document should be ready for a second round of WG LC. Terry Manderson => Anyone has comments on this document? [No comments from the room] Terry Manderson => (to the room) If you think that document 08 is ready for WG LC please hum now. [Consistent number of people humming] Terry Manderson => Please hum if you believe this document is NOT ready for WG LC. [nobody humming in the room] Terry Manderson => Thanks, we will take it to the ML. When we go for WG LC on the ML and we ask for reviews please do it. draft-ietf-lisp-eid-block-mgmnt (Luigi Iannone) Document: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-01 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-1.pdf ================================================= Geoff Huston => The ending paragraph of section 4 goes? Luigi Iannone => Yes. Geoff Huston => In section 5 there are some normative word there (RFC 2119), do you really want to use normative words in an informational RFC? Joel Halpern => It is allowed, the question is whether it is intended. Geoff Huston => Yes, if it is ok, that's ok. Geoff Huston => Back to section 4, you talk about 99% of the time, do you really want to enforce such figure? You can state the same intent without being so specific. Luigi Iannone => The main message there was to provide a reliable service. I agree we can be less specific, rewording the sentence without numbers, if this is ok. Geoff Huston => Perfect. Geoff Huston => About the allocation fees, this is more an IANA/IESG problem rather that something to be decided in the WG. Luigi Iannone => If people think is better we can avoid mention fees. I see no issue there. Joel Halpern => Can the authors please summarize the requested changes send them on the list to see if people agree? Luigi Iannone => Sure. draft-farinacci-lis-crypto (Dino Farinacci) Document: http://tools.ietf.org/html/draft-farinacci-lisp-crypto-00 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-9.pdf ================================================= Joel Halpern => (On the Diffie-Hellman slide) To avoid sending around "p" and "g", we can ask the SaaG WG to create a registry of values for "p" and "g" that are good values and you ship just an ID for them. Michiel Blokzijl => Each time you receive a Map-Request you generate a key for the requester, what if you are flooded by requests? You are going to spread your keychain to thousands of requesters and store them locally? Joel Halpern => Thousands of keys is a tiny amount of space, the computation of a continuous stream of keys is the issue. Dino Farinacci => The key is a piece of information like RLOCs, is the computation load that is high, but if you want security you have to pay something. Michiel Blokzijl => But you need to apply Diffie-Hellman thousand times. Joel Halpern => Yes, this has to be covered in the draft. Dino Farinacci => Yes, but if you have several RLOC for the same ITR then you can use a shared key to reduce the load but we need to know how much security we want there. Is a hard trade-off to make. Joel Halpern => We need to add text on that. Dino Farinacci => Yes. Fabio Maino => These types of mechanisms try to push the load on the requesters, so we can think to another message that ask the requester "send me back this message if it is really you". Joel Halpern => Yes, but the challenge violates the fact that we want to do only one exchange. My suggestion is to write text on this trade-off and what the working group thinks about it because any answer is the basis to discuss what is the best answer. Fabio Maino => It would also be interesting to see how this can be applied to lisp-gpe and vxlan-gpe because there we can relax the restrictions we have on the header format. This way we can use more standard ways to do encryption and authentication. Dino Farinacci => By adding more header space? Fabio Maino => Yes, for example. Dino Farinacci => I should have added the requirement to not add more space to the header. Fabio Maino => Yes, but this will need hardware change anyway. Joel Halpern => Robert Raszuk brought up in the ML that we need to be able to use generic algorithms at least for encryption and may be for key generation. I need to talk with the security people. To do this in a one round trip time may need more information in the Map-Request/Map-Reply packet format. Dino Farinacci => We need to do what we can to keep this out of the mapping system. Joel Halpern => As long as we keep the information in the Map-Request/Map-Reply it should work. But we need to support agility in these two dimension otherwise security people will tell us to fix it. draft-freitas-bellagamba-lisp-hybrid-cloud-usecase (Santiago Freitas and Patrice Bellagamba) Document: http://tools.ietf.org/html/draft-freitas-bellagamba-lisp-hybrid-cloud-usecase-00 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-2.pptx ================================================= Dino Farinacci => (on the use of IPSec tunnel to traverse NAT) That is why integrated solutions work well. You can take a NAT traversal design and a Crypto design and put them together in this use case. For user this will be much better. Patrice Bellagamba => Yes. Joel Halpern => Once we clear the blocking documents we will be discussing the introduction of new use cases. There are lots of new things, like this document, that we will discuss at the point. Dino Farinacci => Does this use case have any special new requirement in multicast? Patrice Bellagamba => We did not work on that yet, so at this point I do not know. draft-moreno-lisp-datacenter-deployment (Victor Moreno) Document: http://tools.ietf.org/html/draft-moreno-lisp-datacenter-deployment-00 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-3.pptx ================================================= [No questions from the room] MONDAY, March 03, 2014 1630-1730, Session 2 (of 2). 60 Mins [Skipped afternoon break] ================================================= draft-hertoghs-lisp-mobility-use-cases (Yves Hertoghs) Document: http://tools.ietf.org/html/draft-hertoghs-lisp-mobility-use-cases-00 Slides: Missing Slides on the material page (last checked 13 Mar 2014) ================================================= Joel Halpern => (On use case 3) How to make sure that the host registers itself? In a DC the orchestrator knows that a hosts moved, but in a generic domain how to know? Yves Hertoghs => We can use the same idea like wireless mobility but we did not add text yet. But there are also DC specific techniques that we can use like intercepting host traffic. Dino Farinacci => (on the overview slide) If the NVO3 comes here asking to use your overlay which of your 7 cases you would recommend? Yves Hertoghs => Then 5 would be my choice. If you have xTR that can accept register for both IP and layer 2 and can forward IP and non-IP traffic, then it seems to cover all the use cases of NVO3. Joel Halpern => A comment to the presenters of the last three documents. Thanks for bringing this work here. However, what strucks me is the fact that we have three drafts with overlapping use cases coming from the same company. Darrel Lewis => We are all individuals here. Joel Halpern => Yes. Independently from that we either combine or disambiguate. Would be good if they do not overlap. Yves Hertoghs => Fair point. But we could have a distinguished deployment guidelines section. Darrel Lewis => Some of these mobility use cases may require protocol extension, so there is a third dimension along different use cases and deployment guidelines. Joel Halpern => Uses case are interesting and will drive us to do something. From the WG perspective, this can lead to work on protocol to address gaps identified by these use cases. That is why use cases need to be clear. Darrel Lewis => Yes, and as part of the re-chartering we should probably work on a taxonomy of these use cases. Yves Hertoghs => And either collapse the document or disambiguate. Joel Halpern => Yes, and I am not complaining about the number but their relationship is not clear. draft-coras-lisp-re (Florin Coras) Document: http://tools.ietf.org/html/draft-coras-lisp-re-04 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-10.pdf ================================================= Dino Farinacci => One of the thing we should look at is multi-homing at the source. Back when we where working on PIM the question was: "Do you want the core to decide whether the replication should be done at the source?" If there are two RLOC of the same site that join separately, then may be you have to do replication. We need to think about it. Darrel Lewis => You indicated that RTRs are close to 1 and 2, how is that determined? There is any previous knowledge? Florin Coras => Is configuration, you provision RTRs to do replication for the source. The other approach would be to have the Map-Server to dictate this, by having some additional knowledge. One last approach is to have a third party that configures the whole topology. Concerning how the ETR know it is close to 13: is BGP. The ETR requests who are the upstreams and the mapping system provides the leafs. Who decides who is leaf and who is not? We go back to point 1. But now the ETR can choose between 11, 12, 13. Dino Farinacci => A way to thing at this is to have a level 0 consisting in a TE box close to the source and level N TE boxes close to the potential destinations, so based on the source address you can decide if it is level0 or level N. Darrel Lewis => The relationship looks somehow arbitrary. Florin Coras => For now it is configuration. draft-kouvelas-lisp-reliable-transport (Isidor Kouvelas) Document: https://tools.ietf.org/html/draft-kouvelas-lisp-reliable-transport-00 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-5.pptx ================================================= Gal Mainzer => What about non-proxy mode and the communication between ITRs and ETRs? Isidor Kouvelas => This is just between ITRs and Map-Servers and does not change the way Map-Requests are processed. Gal Mainzer => What is the Map-Request is forwarded to the ETR? Joel Halpern => We change just the registration process, not the request process not the reply process. Michiel Blokzijl => In the current specification we have a limit in the numbers of elements we can pack in a Map-Register, because of the MTU. With TCP we can be able to pack 256 RLOCs, especially IPv6 addresses, whereas previously was not possible. Joel Halpern => We still ne to change Map-Replies. Michiel Blokzijl => So we do not deal with this? OK. Isidor Kouvelas => Note that we did not change at all the definition of Map-Register. Dino Farinacci => This can be also save battery life on mobile phones. Isidor Kouvelas => You still have to run the TCP session, so if the number of RLOCs is low you do not gain that much. Joel Halpern => Did you specify, in the draft, what to do when the transport connection comes up? DO you register everything again? Isidor Kouvelas => Yes you register again. It is written in the state machine. Actually is the Map-Server that requests a refresh. We can easily implement some state on the Map-Server so to allow things like "send me everything beyond this progress point so to avoid exchanging the complete state. Joel Halpern => That seems powerful. Thank you. draft-farinacci-lisp-signal-free-multicast (Dino Farinacci) Document: http://tools.ietf.org/html/draft-farinacci-lisp-signal-free-multicast-00 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-4.pdf ================================================= Joel Halpern => If we have several ways to handle multicast, the ITRs can support one or more of them, the ETRs can support one or more of them, how will they know how to do the actual communication? Dino Farinacci => We need some negotiation somewhere, like in the crypto case. Joel Halpern => May be we can again put something in the Map-Request/Map-Reply, but looks like putting things in the registration is not enough because is a harder problem. Dino Farinacci => I would be happy to say that we are ready to converge on one solution, but we are not yet there. drat-rodrigueznatal-lisp-sdn (Albert Cabellos) Document: http://tools.ietf.org/html/draft-rodrigueznatal-lisp-sdn-00 Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-6.pdf ================================================= Dino Farinacci => Flow caching is scary. We will have a scaling issue in the forwarding plane. I think we can get the 5-tuple to work with DDT, just put a destination address at the top of the hierarchy. But if we have to find the mask of the 5-tuple equivalent it is going to be difficult. Albert Cabellos => Agreed. You are suggesting to use the destination address on top of the hierarchy and go down, up to the source port. Dino Farinacci => I did something similar for S,G, where G can be specific and S can be coarse. But you need to do a conscious decision on who has precedence, and you want to change this? or you want to hard code it in the architecture? These are hard decisions to make. Albert Cabellos => I fully agree. Gal Mainzer => If we talk about SDN, then we talk about service chaining, if we do such kind of lookup at every hop then we will add latency to each packet. We should consider doing this only at the first hop. The first hop can push the information to the rest of the hops. Albert Cabellos => Good point. Thank you. Joel Halpern => One can note that LISP has provision to carry multiple hops in the packets. Darrel Lewis => Whether you use ELP, like has been presented during the last meeting to do segment routing, or this solution there are three areas that break out that come out and must be considered: - Flow type information in the mapping system - Flow type information in term of the map that has been required - Path information If you can separate them you combine them for the different use cases. Albert Cabellos => Yes. Luigi Iannone => I have a comment about the suggested Publish/Subscribe mechanism. I think we somehow have it already. If an ITR register a mapping, then it is publishing it. If an ETR request a mapping then it is subscribing to the mapping. If something changes, we have several mechanism to send a notification saying "something has changed please retrieve the new mapping". May be is not enough but you need to spell out why is it not enough in your context. Albert Cabellos => True. But in this context you are chaining services and you can have recursive ELPs so if you want to operate quickly it may happen that you do not know your peers so things can be slow. That is why we thought about a simple mechanism to which once you subscribe if anything changes you receive the updates directly. But I agree we need to describe in which specific case we need this. Michiel Blokzijl => SDN means a lot of things to different persons. Looking at you presentation a more suitable name would be NFC for LISP or LISP for NFC. Fabio Maino => We do not need names. WE are just learning from the SDN applications, mainly with the open source implementation in OpenDayLight. In this draft we are just highlighting the requirements, if we want to change the name there is plenty of time. Joel Halpern => With that we are done on time. [Session closed] =================================================