Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
Excerpts from Jon Crowcroft on Sun, Feb 01, 2009 09:30:55AM +: you can push info multiply redundently (or cross-post:) and you get reliability with a silly overhead or you can push an update which is wrong and disconnect the entire world, e.g. http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.html so aside from the basic academic type scaling, has anyone done this sort of disaster-prone analysis for LISP/ALT? There is a concern about misconfiguration. Certainly you want at least doublechecking, and possibly signatures. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
Dino - I think we should experimentally compare ALT with other mapping systems before we decide whether pull-based or push-based mapping systems are better. Dismissing push-based mapping systems without corroborating data would be a bit premature in my opinion. Agree. In the absence of experimentation results, I would actually argue in favor of push-based mapping systems based on some analytical reasoning: Pull-based mapping systems have two important disadvantages compared to push-based mapping systems: - Performance penalty, i.e., additional propagation latencies for some packets, and higher loss probabilities for packets that take a sub- optimal path - Robustness penalty due to a new online dependency on components off the actual transmission path. (FWIW: All pull-based mapping systems have this penalty. Mapping requests must be routed via overlay infrastructure because the direct route is unknown at that time.) Make note that LISP-ALT is a hybrid. It pushes EID-prefix announcements via eBGP over an alternate topology of GRE tunnels. And then ITRs pull the mappings by sending Map-Requests on this topology so ETRs (who are authoritative for the mappings) can return Map-Replies. Furthermore, I do not share your concerns regarding push-based mapping systems: BGP is pushing routing data already today, and this works fine. Any routing-scalability-related issues with BGP are not due to But the BGP RIB is order 10^5 and on average (there is lots of data on this) only 10% of that table is used in any given router. BGP being push-based; they are due to frequent updates and a high load for core routers. Both of these issues would go away in an address Other reason you want to push is if all the nodes in the push domain need to use the information. If they don't it is a waste of memory and resources. BGP is used as a transport for routing information but each node uses that information. Make note that NERD has been called a push mechanism. But it actually is requesting to receive *all mappings*. Also, another point I want to make where I'll use the iPhone 2.0 release as an example. In 2.0, they said they had push email. Well from a user point of view, that means when you open your mail app, the email is sitting there ready to be read. If in the background, there was a periodic process to pull the email, then it still looks like push. The point here is begging a single question: 1) Should all the mappings in the universe be in an ITR? 2) Should only the mappings for sites the ITR is currently talking to be in the ITR? This is the important matter. Decide on that then we can talk about how to get the mappings where they need to be. In conclusion: The overlay approach of ALT is certainly an interesting idea. But I think it would be premature to conclude that it is the only viable solution before we have more evidence to back this claim. Why do you think a conclusion is being made. I haven't made any. Anyways, this is a good discussion and glad we have moved passed the definition of an EID. Dino ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
On Jan 28, 2009, Dino Farinacci wrote: You cannot push around 10^10 entries and store them everywhere. [...] Dino - I think we should experimentally compare ALT with other mapping systems before we decide whether pull-based or push-based mapping systems are better. Dismissing push-based mapping systems without corroborating data would be a bit premature in my opinion. In the absence of experimentation results, I would actually argue in favor of push-based mapping systems based on some analytical reasoning: Pull-based mapping systems have two important disadvantages compared to push-based mapping systems: - Performance penalty, i.e., additional propagation latencies for some packets, and higher loss probabilities for packets that take a sub- optimal path - Robustness penalty due to a new online dependency on components off the actual transmission path. (FWIW: All pull-based mapping systems have this penalty. Mapping requests must be routed via overlay infrastructure because the direct route is unknown at that time.) Furthermore, I do not share your concerns regarding push-based mapping systems: BGP is pushing routing data already today, and this works fine. Any routing-scalability-related issues with BGP are not due to BGP being push-based; they are due to frequent updates and a high load for core routers. Both of these issues would go away in an address indirection architecture (be it LISP, Ivip, APT, or Six/One Router), independent of whether you use a pull- or push-based mapping system. In conclusion: The overlay approach of ALT is certainly an interesting idea. But I think it would be premature to conclude that it is the only viable solution before we have more evidence to back this claim. - Christian PS: I admit that I have never been really good in avoiding cross- posting. But this is obviously my all-time negative record... ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
Jari Arkko: In particular, I would like to know how people feel about this work being ready for an (Experimental) IETF WG, what the scope should be, whether the charter is reasonable. And if not, what would make it so. +1 for an Experimental IETF WG scoped to develop an RFC series on LISP protocol, routing, and addressing. The most recent charter proposed by Dave Meyer looks good to me. Cheers, -Benson This message contains information which may be confidential and/or privileged. Unless you are the intended recipient (or authorized to receive for the intended recipient), you may not read, use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachment(s) thereto without retaining any copies. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
On 1/20/09 7:59 PM, Schliesser, Benson bens...@savvis.net wrote: Jari Arkko: In particular, I would like to know how people feel about this work being ready for an (Experimental) IETF WG, what the scope should be, whether the charter is reasonable. And if not, what would make it so. +1 for an Experimental IETF WG scoped to develop an RFC series on LISP protocol, routing, and addressing. The most recent charter proposed by Dave Meyer looks good to me. +1 -J Cheers, -Benson This message contains information which may be confidential and/or privileged. Unless you are the intended recipient (or authorized to receive for the intended recipient), you may not read, use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachment(s) thereto without retaining any copies. ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
On Jan 20, 2009, at 2:59 PM, Schliesser, Benson wrote: The most recent charter proposed by Dave Meyer looks good to me. aye___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
Hi Ross, It seems to me that you and Dimitri are talking about things that the RRG should be doing as it moves towards conclusions. I don't see why they would be in scope for an IETF LISP WG, where we would ask for a tight and achievable focus. Obviously there's a risk in chartering a LISP WG now: that the RRG will come out with a significantly different recommendation at some date in the future. The IESG can decide to take that risk if it likes. But I don't see the point in a second BOF; the idea that a BOF could resolve in a couple of hours the issues that the RRG has been discussing since early 2007 seems unlikely. Brian On 2009-01-22 05:26, Ross Callon wrote: In order to make an ID/Loc split work on an Internet-wide ubiquitous scale, we need very good solutions and/or greater understanding to some hard questions such as what will be the granularity of the mapping function (how large will the mapping table be and what granularity of prefix will be in it), how to do the mapping, how to do liveness detection, what the scaling properties of the mapping and liveness detection functions is likely to be, and what the manageability, security, and robustness implications are. I guess that while we are at it we need to figure out if there are other issues, such as MTU, that need consideration. If you want to do experimentation on a moderate scale, then answers to these questions are not strictly needed. I didn't see any of these hard issues explicitly mentioned in the proposed charter (although there is mention of the LISP+ALT mapping system). Is this because the effort is intended to be focused on the shorter term experimentation efforts (including experimental protocol specs that allow the immediate experiments to occur), for which these hard issues do not need to be answered? Thanks, Ross -Original Message- From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf Of Eliot Lear Sent: 21 January 2009 08:56 To: PAPADIMITRIOU Dimitri Cc: int-area@ietf.org; l...@ietf.org; routing-discuss...@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: All items in the charter - see below - are exclusively oriented toward LISP protocols implementation specifics, and interworking: Right. This is a LISP WG. There is nothing stopping anyone from creating another WG, assuming the work warrants it. And again, the output is experimental docs. No standardization choices are being made. ___ lisp mailing list l...@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
Jari, But back to the proposal. In particular, I would like to know how people feel about this work being ready for an (Experimental) IETF WG, what the scope should be, whether the charter is reasonable. And if not, what would make it so. There are reasonably stable specs that people can code to, there is code, there is a running network, there is a community of interest (myself included), and there are some interesting questions to answer still (like liveness and EID/locator update) that are ripe community involvement. So yes, I think it would be useful to provide a forum for the community to discuss and evolve this work. Eliot ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
