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 AT net.t-labs.tu-berlin.de ) 1540-1710 Monday 30th July 2012. Session 1/1 (100 min) =-=-=-=-=-=-=-=-=- Agenda bashing: --------------- Note Well and Blue Sheets. Jabber scriber: Luigi Iannone and Wassim Haddad are in charge (beside taking notes) No comments from the room concerning Agenda WG Draft updates ================ LISP-MIB: Darrel Lewis http://tools.ietf.org/wg/lisp/draft-ietf-lisp-mib/ ================================================== Terry Manderson => What is the situation in terms of deployment? Darrel Lewis => We got feedback that it will not be deployed until it is not set in stone. Dino Farinacci => The biggest problem is that operators will not deploy unless there is a MIB, vendors do not want to implement the MIB until there is object EID space that is global rather than proprietary. So if specifications take long to be adopted can we at least go forward and request assignment of object EIDs? Joel Halpern => The right answer is let's focus the WG to look at it and let's get it done. This document is not depended on anything else, once we have IESG approval we can have the code points assignments. It can be argued that since it is an experimental document anyway, what we hope is that vendors will implement it, first of all to make sure we did everything right in the MIB. Darrel Lewis: please progress it so we can implement it Terry Manderson => So, are authors claiming this is a stable document? Darrel Lewis => That was the goal of the latest version. Vince Fuller => Operators are happy with it and hope vendor will implement it. Terry Manderson => So authors want which next step? Darrel Lewis => WG Last Call. Terry Manderson => OK. Let's take it to the Mailing List and issue the last Call. Other Drafts ============ LISP-Architecture & LISP-Introduction: Vince Fuller http://tools.ietf.org/html/draft-chiappa-lisp-architecture-01 http://tools.ietf.org/html/draft-chiappa-lisp-introduction-01 ============================================================= Vince Fuller => Question for the WG and the Chairs: is this the kind of material the architectural requirement is looking for? Are these documents going in the right direction? Has anybody read these documents? [very few hands rose] Joel Halpern => I recommend folks to read them. The goal is for them to be an accurate and readable description of what we are doing. The best way to achieve that is to have people look at them Fabio Maino => I started late with LISP and working all the way through the documents is quite a challenge. Both are good, especially the introduction. Vince Fuller => Which contains also some history on what we did look at and what actually scales and is working. Vince Fuller => Is this for the chairs the right direction? Joel Halpern => I think these are the right answer to what the IESG has asked us to do. I invite people interested in LISP to look at them. I was hoping to have a preliminary call for adoption, but since very few people read the documents better formulate the question in a negative way: Is anybody that read the documents objecting their adoption? Anybody here who has concerns? [No reaction in the room] Joel Halpern => Ok, we will take it to the list to have a call for adoption. LISP-DDT: Vince Fuller http://tools.ietf.org/html/draft-fuller-lisp-ddt-03 =================================================== Darrel Lewis => There is web page ddt-root.org for who is interested. Joel Halpern => From an ITR, am sending a Map-Request, from a DDT perspective is it the same Map-Request? Vince Fuller => The ITR sends the same MAP-Request. It is basically an encapsulated Map-Request. Joel Halpern => So the ITR and MS interface is not changed. Vince Fuller => Yes, it did not change. This is all in the DDT specifications. Dino Farinacci => The MS/MR interface does not change at all when switching mapping system. Joel Halpern => I was thinking that LIG was running like a MR. Dino Farinacci => LIG is a tool that process Map-Replies that come back and can run anywhere in the system. RIG is a tool that sends the same type of Map-Requests but what it expects back is Map-Referrals. You can go to any node in the tree, send a Map-Request to obtain the referrals or you can walk the tree. Joel Halpern => WE have later on other mapping proposal to be presented. Sometime in the future, the chairs will ask for adoption of one of them, the WG is invited to read the document. Vince Fuller => We will ask soon for adoption. LISP-DDT is running consistently on the Beta network since April. Darrel Lewis => There are also 2-3 operators offering DDT services. LISP-LCAF: Dino Farinacci http://tools.ietf.org/html/draft-farinacci-lisp-lcaf-10 ======================================================= Li Cheng => Question concerning the L-bit. The L-bit is used to send a Map-Request, it means that a Map-Request for the field address, which in this case is an RLOC. This means I need to send a Map-Request for an RLOC? Dino Farinacci => It means that for each address in this field, you can either encapsulate or do a lookup in the mapping database. If it is an RLOC then you encapsulate, if the L-bit is set then it is something else so you query the mapping system. It could be an EID, but can be something else if you are using recursion. Dino Farinacci => What should we do with this document? It is an individual submission, should we keep it this way or adopt it as WG document that can be referenced by other documents? Terry Manderson => What would the WG like to do with the document? Anybody objecting? Otherwise I'll go for a call of adoption. Luigi Iannone => There are continuous references to this document in the whole set of LISP documents, so in my opinion, let's make WG document and harmonize all documents and make everything coherent. Terry Manderson => Who read the document? [few hands rose] Terry Manderson => Probably not quite enough for a call for adoption. Does anybody object to a call for adoption? [No reaction in the room] Terry Manderson => We will make a formal call for adoption on the list. LISP-TE: Michael Kowal http://tools.ietf.org/html/draft-farinacci-lisp-te-01 ===================================================== Joel Halpern => The mapping system is not tight to the data plane of an operator, the mapping system is in fact orthogonal to the operator providing data plane services. So the mapping system cannot give me information about the data path. Darrel Lewis => This is a good example. What is not shown here is the service providing mappings for the ETR needs to be the same providing mappings to the RTR. Joel Halpern => I was expecting that. Why this should happen? Mapping Service providers do not provide data plane boxes. Dino Farinacci => OK Joel. First of all, it is a question of using more mapping systems. If you use a private mapping system in the transit then you can play these games. In a global mapping system, everybody reads from the same system, so everybody should have the same answer. However, you can have multiple things right to it. Different providers can add to the mappings, you can have multiple writes. There must be agreement between services providers to control who has the right to write something in the ELP. This is something that any SDN API can do. Joel Halpern => But I do not see the business relationship so that the mapping service provider would know. Dino Farinacci => The mapping service provider would know who is registering the piece of information. Joel Halpern => But only some customers need to receive these scrubbing services, so how do they receive the right answers? You would need several mapping service providers, this could be a nightmare. Dino Farinacci => You can use S-D masks. Ok, let's take it offline. Joel Halpern => I think that the problem of an ITR injecting information about an ISP topology, and the ISP is counting on the customer to get its behavior right has similar issue as who you expose the information to, how do you know that the right thing is going to happen. I see reasons to explore this space but it needs a lot more work. Dino Farinacci => We can spec that the ITR has no changes, and who is putting the information in the mapping is something to be agreed upon. If there is a service provider and several customers you can easily see how it can be deployed. Joel Halpern => If it is a single service provider in its own network with its own mapping service, it can play lots of games. But I expect some much broader than that. There is more work to be described here. Terry Manderson => Based on this exchange, we believe this needs more work before any further step. LISPcast: Florin Coras http://tools.ietf.org/html/draft-coras-lisp-re-00 ================================================= Joel Halpern => How many people read the draft? [ few hands rose in the room] Joel Halpern => Any other comments from anyone? [no further comments from the room] Joel Halpern => OK we move on LISP ITR Graceful Restart: Damien Saucez http://tools.ietf.org/html/draft-saucez-lisp-itr-graceful-00 ============================================================ Darrel Lewis => Can you have traffic using two equal cost multipath (ECMP)? So that you populate both map caches? Damien Saucez => You could but you can always have a subnetwork with something else. Joel Halpern => I am not sure that using ECMP multipath will really help that much since some flow will go only one way. ECMP is clear on that. Darrel Lewis => We have experience with implementing the first of your three solutions: storing the map cache in a non-volatile RAM. Seems to work and seems not to be used that much. In real deployments, we do not tend to reboot that often. The fact that it takes 5 minutes to reboot plus 30 seconds to populate the cache does not matter compared to 5 minutes to just reboot. So I am wondering what are the benefits compared to the cost of all of this. Having said that, I think is interesting worth to explore it. Darrel Lewis => The other thing: we were talking about mitigating packet drops upon cache miss, by forwarding to a PxTR that has a perfectly functioning map cache. Did you explore this idea? Damien Saucez => This is a kind of deflection. Just instead of deflecting to an ITR inside the network you deflect to an ITR outside the network, and this is how we implemented the deflection when we tested it in the lab, by using a PITR and a PETR. Dino Farinacci => Wondering if you can merge two of the approaches into one. Instead of the deflection sending a Map-Request to the mapping system you can send the Map-Request to another ITR to obtain the mapping with a lower latency, being a local function. Damien Saucez => Yes, it is something possible. Another solution is to do caching at the Map Resolver, always asking the MR that is closer. Terry Manderson => We are running short in time, let's take it offline and continue for the last presentation. LISP SHDHT Li Cheng http://tools.ietf.org/html/draft-cheng-lisp-shdht-01 ==================================================== Joel Halpern => There was a big discussion on the mailing list about responding to the query within the system rather than from the ETR. Is this an intrinsic design or could you possibly send the request to the ETR, which will reply? This would be similar as other mapping systems do. Li Cheng => Yes, this has been discussed on the mailing list. One of the reasons to request ETRs to reply directly is that they can have different policies depending on who is requesting the mapping. However, it is my opinion that such policies can be replicated in the Map Server. We will consider it in future versions. Dino Farinacci => Let's assume that this SHDHT is implemented by multiple mapping service providers, and let's say one also assume that a new mapping service provider wants to participate and be injected in the ring, do all other service providers need to be re-assigned? Li Cheng => No, according to our deployment consideration, we can have several instantiation of the SHDHT by different service providers, and we have considered an overlay for their interaction. Dino Farinacci => What if the request is for 1.1.1.1 in the other example and it is supported by one single mapping service provider because of the address allocation? Li Cheng => I think that different service provider can maintain different prefixes. First, the overlay will determine to which SHDHT the request should be sent. Dino Farinacci => In slide 6, is this design assuming that Map Servers and Map resolvers are not part of the system? It looks like it assumes it is not. Is this true or not? We wanted that the ITR/ETR all have the same mapping database API, with Map-Requests going to Map Resolvers and Map-Register going to Map-Servers. By having that model, we were able to make the mapping database transport system between Map Resolvers and Map Servers modular. If you do not do that you are going to request changes to ITRs and ETRs. Is that what you are requiring? Li Cheng => I see and I will consider this problem. Terry Manderson => We are out of time, send comments on the list. Please read the documents, I have seen 7 raised hands at most today, as working group more interaction is needed. People are expected to read the drafts and provide comments. [Session closed] ============================================