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 ( luigi.iannone AT telecom-paristech.fr ) 1300-1500 Monday 6th November 2012. Session 1/1 (120 min) =-=-=-=-=-=-=-=-=- Note Takers: Luigi Iannone and Wassim Haddad Jabber scriber: Damien Saucez Note Well! Current drafts in RFC Queue (Cluster 62) ========================== draft-ietf-lisp-alt draft-ietf-lisp-interworking draft-ietf-lisp-lig draft-ietf-lisp-map-versioning draft-ietf-lisp-ms draft-ietf-lisp-multicast draft-ietf-lisp (main specifications) The last just came back from the IESG and a revised version is awaited. It is expected to move forward ASAP. Comments from AD Brian Haberman ========================= Brian Haberman => A couple of the discusses from the IESG concern the UDP checksum and the related documents discussed in the transport area (draft-ietf-6man-udpzero and draft-ietf-6man-udpchecksums). These documents are going under a lot of restructure. The udpzero document is going to be a feasibility statement, and because of this change in status it has to go again through WGLC, so if possible I will start TSVWG and IETF last calls at the same time. Dino Farinacci => And the duration of these last calls is? Brian Haberman => Two Weeks. Brian Haberman => Two more documents are blocked by the AD at the IESG: draft-ietf-eid-block & the draft-ietf-lisp-mib. For the eid-block document I am waiting for a revised version (for 55 days). [Additional Note from MT: The revised document (draft-ietf-lisp-eid-block-03.txt) has been submitted two days later.] Agenda bashing: --------------- No modifications to the proposed agenda. WG Draft updates ============= LISP-LCAF: Dino Farinacci https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ ============================================ Brian Haberman => In the SNMB community there are other Inet Address type that have the same general purpose. Have this been considered here? Dino Farinacci => Inet Addresses do not support all the types defined in this document, so it won't be sufficient. Brian Haberman => The option that was mentioned was to simply extend the Inet Address to include the LCAF Address Family. Dino Farinacci => Does Inet Address enumerates also all of the addresses that AFIs do? Brian Haberman => No, so far it enumerates IPv4, IPv6, and there is a type in DNS name. Dino Farinacci => So if you use a MAC address as an EID, which is AFI 6, is it supported? Brian Haberman => You have to define it. Dino Farinacci => So it is much more flexible if you use LCAF. Brian Weiss => The security type entry need a lot more explanation, otherwise you will have strong comments from the security ADs. LISP-Threats: Luigi Iannone https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ ============================================ Presenter asks to go for WG LC. Darrel Lewis => I think the text needs work but without a deadline nothing is done. What I mean is that the document is ready for LC. The changes that are needed can be done in a matter of days. So, I support LC. Where the document can be improved is the difference in how to mitigate the threat, whether via operational techniques (e.g., ACL) or by adding some features to the protocol. Second point is that the document could use more clarification on difficulty to perform the attack. For instance, if you to compromise an ETR and re-write the code on it to perform an attack, there is nothing that configuration could do. But these are all issues simple to solve. Luigi Iannone => Yes, text can be still changed. In the document we clearly state what can be done from an operational point of view, but we not suggest to change whatsoever in the protocol. Of course there are attacks that can succeed only if a router is compromised, but is not the purpose of LISP to protect routers, and we clearly state that. Terry Manderson => I think that everything can be addressed during a LC, and we do not need to "boil the ocean", and we are not going to solve every security problem of the Internet that may impact LISP. We just need to be aware of them. We will take it to the list and issue a LC, unless there is someone going to the mic stating this is a very bad idea. [Nobody at the mic] Terry Manderson => Any comment from the Jabber? Damien Saucez => No LISP-DDT: Vince Fuller https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/ ============================================ Darrel Lewis => There is a site named ddt-root.org about DDT. We have a few servers running as DDT root, but anybody willing to participate an instance of an existing root server or run a new root server can find all the necessary information there. Sharon Barkai => If somebody want to adopt this as a basis for SDN, is it somewhere defined how to do that? Is it the gap between this and SDN defined somewhere? Vince Fuller => You mean LISP or DDT? Sharon Barkai => LISP in general, but DDT specifically is one of such gap, because the lookup is hierarchical, there is anything to make the lookup for distributed entities flat and support any pattern matching? Vince Fuller => Basically, we were working to different database proposals. DDT is specifically designed to be hierarchical like DNS. So I think that your question is outside the scope of DDT, but not outside the scope of LISP. There is nothing to prevent the implementation of new database for your purpose that is also able to integrate with Map-Servers and Map-Resolvers. They way how LISP is designed is with another level of indirection between the ITRs and ETRs and the database, this interface are the Map-Servers and Map-Resolvers. You can easily design a new SDN database that can be integrated with Map-Servers and Map-Resolvers, but this will not be DDT. Dino Farinacci => Concerning the SND part of the question. SDN is there to provision networks, configure routers, switches, etc.. You can use an SDN application to program map cache entries in routers. Today device learn mappings dynamically and register also dynamically to the mapping database system with protocols defined in this WG. One can argue that instead of having devices registering the mappings, an SDN application can do that, or even program a mapping database directly. Where before there was an xTR and a Map-Server now you can have an SDN application telling the router which EIDs have which locator. So it is the SDN application deciding whether or no an EID mapping is admitted in the mapping database system. There is a scalability benefit if you can program the mapping database. For instance in the mobility case, no matter where you roam you can always register to a Map-Server, because it is static and in one location, while your locators are different because you are roaming. So if we want to avoid the level of indirection where SDN application program devices that register to Map-Servers, we can thing to SDN application directly programming the mapping database, and then the device gets the information from the mapping database. This are just ideas, but a lot of policies and security can be done with these kind of ideas. Sharon Barkai => So the use case scenario would be to take the LISP mapping information at the edge and push it to instead of routers to OpenFlow switches that do not run any other routing protocol. What you need is just a mapping function from flat EIDs. Dino Farinacci => In this context you can have just one single powerful Map-Server/Map-Resolver and the SDN application just needs to program that server. But if you want people to read this information, now you need that distributed and have your Map-Resolvers in various spots. Basically, you publish with an SDN application and you subscribe through a Map-Request/Map-Reply transaction. Sharon Barkai => Other than LISP there is no central controller, it is a distributed database with local access. Dino Farinacci => Yes. You can see it as designed as a monolithic centralized database, which is actually implemented in a distributed way. Luigi Iannone => Going back on the OpenLISP status. I have no updates on OpenLISP itself, however, there are people in Paris, at University Paris VI, that are working on a LISP control Plane based on the OpenLISP Data Plane. They are progressing and just implemented Map-Server and Map-Resolver features. Will send link on the mailing list for people interested. [Note: This has been done on November 14th http://www.ietf.org/mail-archive/web/lisp/current/msg03998.html] Vina Ermagan => Coming back to what Dino said, there are different mapping systems that have been discussed for LISP. Some are flat, some are DHT based, but we looked at hierarchical system because of scaling, which is a key point. LISP-Deployment Albert Cabellos https://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/ ============================================ Presenter asks to go for WG LC. Darrel Lewis => Since we have LISP Proxy providers, I want to give a little bit of an update. When switching customers from BGP announcements to LISP announcements we have seen a decrease in the order of 25% in the DFZ. The reason of the decrease is that there is a number of customers that do not need to de-aggregate anymore. Joel Halpern => This is useful information to be included in this document. Albert Cabellos => You mean the specific value? Joel Halpern => The thing to document is that there is deployment going on, that there is people that did the move, and that seems that the number of entries in the DFZ is decreased. Darrel Lewis => We are talking about customers already announcing the prefixes. Joel Halpern => Yes, this will increase the impact of the document. Joel Halpern => Why the need to configure the RLOC of Map-Resolvers on ITRs? Why this cannot be done by putting RLOCs in a DNS entry? Darrel Lewis => It is just implementation. Albert Cabellos => Yes, implementation, no specific reason. Joel Halpern => We should state that DNS can provide the RLOCs, otherwise we will have the question during the review. Darrel Lewis => Concerning the BGP overlay. There are two cases where this overlay makes sense. When you are a proxy provider and you have a lot of proxies, then it make sense to have an overlay to so to make configuration changes in one place and automatically distribute it to all edges. The other case is when you have different Proxy ITRs that essentially want to do peering, announcing each others' EID space. I will check if the current text captures these cases. Albert Cabellos => I think is already there, but we can check. Darrel Lewis => The document is ready for LC. Terry Manderson => OK, the LC review will include today's comments. We will take it to the list. Florin Coras (through jabber, relayed by Damien Saucez) => Referring to Joel's comment, do DNS entries relate to RLOCs or EIDs? Darrel Lewis => The RLOCs of the Map-Resolver. Joel Halpern => Yes, RLOCs, not EIDs. LISP-Architecture & LISP-Introduction: Terry Manderson https://datatracker.ietf.org/doc/draft-ietf-lisp-architecture/ https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ============================================ Terry Manderson => This is more an open mic session for people to express their opinion on these two drafts. Terry Manderson => Does the Intro document meets your expectation as an Intro to LISP or does not meet your expectation as an Intro to LISP. Darrel Lewis => I think it meets the expectation for implementer that needs to understand what is all about. Unfortunately the title is makes people using LISP make think it is a good place to start looking at it and it is not scoped for that. Joel Halpern => To some degree that might be ok, because the goal here to write the specs so that people can understand it. If you can see some section that should be added so that makes clear what people are getting from this picture let's put them in. Darrel Lewis => There is a line between what is in charter and what is not in charter. Joel Halpern => We are not trying to cover all possible deployments. There are too many which are not even in charter. But if there are things that complement what is in the deployment document let's put them in. Should be short, otherwise we would loose the deployers and the implementers. Albert Cabellos => I think the first question to ask is who are the expected readers of this document. To me the answer is: people that want to be introduced to LISP, that want to understand what this is. Is this correct? Terry Manderson => No. It is more for deployers and implementers. Joel Halpern => This is meant for people who need to understand the specification to implement them. It can turn out to be deployers because often they ant to understand the protocol behavior. The purpose of the Intro document is to give you the trails and structure to put all the pieces together. The architecture document then gives you the architecture. They started as one document and was becoming very very long and hard to read. Albert Cabellos => So this is the first document that people will read. Joel Halpern => If you are interested in LISP you read the Intro, then you look at the architecture, and then you go to the protocol specifications. Albert Cabellos => I agree with this view. What I suggest is add a very simple section that is the life of a packet. I think is very simple for engineers to read and is very easy to understand what LISP is. Dino Farinacci => This is already in the main specification document. Joel Halpern => We have to see if it fits in the document. Brian Weiss => There is such a section, it is 6.1, but there is nothing in there right now. Joel Halpern => So that should be the section, is just that content is not there yet. Albert Cabellos => OK. But if can be put earlier in the document. Joel Halpern => Yes, there are issues with the document organization, there are words that have to be explained before we use them in the document. We have to know what a map system is, we have to know what an xTR is, etc. That's the reason of the current order. Albert Cabellos => Is just a matter to decide whether we first explain what an then how or how and then what. Darrel Lewis => I think that the entire organization should be adapted. Luigi Iannone => I agree with Albert that the document lacks a bit in providing the big picture. Other than that I think the structure is pretty good. But, while reading the document, I had several time the feeling that to really understand the document the reader has somehow to know some terminology and an idea of what LISP is. Is not about content, is about wording. So I think that we should pay attention to this and may be have a special review of the document: give it to people that do not know anything about LISP, if they understand the documents then we are done. Joel Halpern => I may also ask you and Albert to have a deeper look to the outline and see if there is some section reordering that can improve the document. Brian Haberman => The are members of the directorate that do not know that much about LISP but do now a lot about the architecture of the Internet. So when we will need a review before going for WG LC I can ask those people to review it. Terry Manderson => I want to see more effort on reviewing these documents on the list. We are a WG and we need more to getting this done. Are there any section that does anyone not agree with its content in the Intro document? Darrel Lewis => I think there is some additional reorganization to do, not deletion. To tackle this you can send out the outline that we can agree on. Joel Halpern => You, and everybody, can propose changes. Terry Manderson => Exactly. The ToC is there grab it, review it and propose changes. Currently in the 01 version there are 9 sections that need text. There are people in this room that are able to propose text for those sections? [Raised hands: Darrel Lewis, Vince Fuller, Albert Cabellos, Luigi Iannone] Terry Manderson => Thanks. You will be called upon to provide text. Now going to the Architecture document. Comments? Luigi Iannone => In this document there is discussion about ALT and DDT, which are fine. Something that might be added is a section about general mapping systems, this is what LISP-MS is all about. So, I would extend these points, about the fact that the system is open for new mapping systems. At this point the WG is working on DDT, which is a good solution, but the architecture is still open. Terry Manderson => Yes. Sharon Barkai => The section about local use, it may end up being as important as the use for the Internet. Specifically about data centers and VM mobility, hence, I would put more there. Dino Farinacci => There are a bunch of use cases for LISP that are not in the charter, can these go in this document? Joel Halpern => We should focus on what is in the charter. Yes, there are a lot of other interesting use cases for LISP, but we do not want to spend a lot of energy on them. Luigi Iannone => I support Dino's idea about documenting the different use cases. Ok that the LISP effort started because of the scalability issues of the BGP routing infrastructure, but turns out there are a lot of other use cases. We should consider documenting those. Joel Halpern => Interesting but we need first to finish these documents that are in the charter. Dino Farinacci => But anyone can make an individual submission. Terry Manderson => So, does the architecture document meet your expectations? Dino Farinacci => What if the architecture document says something at high level that is absolutely true but that seems to conflict with documents that are already in the RFC queue, who takes priority? Joel Halpern => While documents are in the RFC queue they can be changed, mostly editorial changes. There is a way to introduce important changes but is not easy. Dino Farinacci => Should the architecture document be compatible with what is already there? Joel Halpern => If something new is learned afterwards there is no problem to put it in the architecture document. For instance we are working on DDT, but we are still publishing ALT. Existing documents in the RFC queue do not need to reflect new knowledge. Terry Manderson => Is there any particular section, in the architecture document as it stands now, which you want to comment on? Anything you do not agree with? [No comments from the room] Terry Manderson => For the sections that need to be completed, who is able/willing to provide text? [Raised hands: Dino Farinacci, Darrel Lewis, Vince Fuller, Albert Cabellos, Luigi Iannone, Damien Saucez, Vina Ermagan] Terry Manderson => Thanks. Terry Manderson => Are there any other comments on these documents? Sharon Barkai => The section about the caching is a bit naive. You should not try to solve the problem in this document but rather document the issues. Eliot Lear (through jabber, relayed by Damien Saucez) => As I wrote on the mailing list, there needs to be slight clarification in the delineation between the core protocol, packet processing, and mapping system. Joel Halpern => According to the charter there is a different document dealing with the impact. That one as to deal with the details of cache behavior and cache management. This is an issue that has been discussed many times. If you think there is more to be said in the architecture document please send text. Dino Farinacci =>There is a lot of activity in datacenters with respect to overlays. In NVO3 there is work on overlays, we have two individual submission that will hopefully become WG documents. If there is additional protocol work that needs to be done, will be done here or in NVO3? Terry Manderson => Is that work based on LISP protocol directly? Dino Farinacci => Yes. Terry Manderson => Then, it should be done here. This is my opinion but you should check with AD. Joel Halpern =>If you want to work on that we need to get the current documents done. Dino Farinacci => Yes, but my question is if we have other proposal in other WG and we need to update the LISP protocol, the work is done here or there? Brian Haberman => Based on my previous experience in different WGs, my answer is to keep all the work concerning the LISP protocol here in this WG. Terry Manderson => Ok, we are done. [Session closed] ============================================