Ross, On 14 Jul 2011, at 04:55, Ross Callon wrote:
> A comment on one particular point from your email... > >> ... However, >> researches have shown that the cache management was not as dramatic as we >> could expect. Of course >> the first study in 2007 was with a mid-size campus network and I could >> understand that you considered >> that the work was not relevant. Nevertheless, the study has been repeated >> this year with a traffic trace from >> an operator (and not a pet-operator, a real one that has millions of >> customer today) and the conclusion is >> the same. > > I have read a couple of papers on this issue, which I believe are probably > the ones that you are referring to. The papers that I read both assume that > the granularity of the EID-to-RLOC tables will be the same as the granularity > of the current top level BGP routing table. If this assumption is wrong, then > the results will be correspondingly inaccurate. > > To me it seems highly unlikely that this assumption is within an order of > magnitude of being correct. At a first glance, the assumption might look bad, but I believe it is not the case. Indeed, the evaluation are made with real BGP feeds to determine the number of prefixes. However, this morning I look my FIB and saw 52% of /24, the rest being less specific than that. So know imagine that the whole Internet become de-agregated, it means that we would have 100% of /24 thus in the very worst case, we would double the number of required entries which remains acceptable. Would you allow prefixes more specific than /24 in EID? In addition, many of the prefixes we are seeing on the Internet are just there because of the incoming TE limitations of BGP (e..g, de-agregation, aspath pre-pending, blah blah) but with mappings you do not need these artifacts and because you have the list of locators and the weight you can even do less specific than /24 with the same result (with better end-to-end control) and at the end one can expect to have the mapping churn lower than the current BGP churn. Another point in favor of this decomposition is that people would probably not be happy to renumber their network and then simply migrate their PI addresses into EIDs. Thus, the current prefix would appear as LISP EID prefixes. So all-in-all, the numbers obtained in the different papers are not so dumb if we assume that LISP is deployed in a smart way by people that know how it works (unfortunately it is not always the case with BGP and we can see absurd announcements everyday), that no configuration mistake are performed (which can be enforced if we ensure security in the mappings and appropriate mapping system, but this is another story) and if we limit the max-deaggregation into /24 for IPv4. In IPv6 I would not announce anything as it is still blurry how IPv6 BGP will really look like (do we really conserve the aggregation we have today?). Does it go in favor of these studies or not? If not, could you discuss with us off-list to design a worst case scenario that we can study to see how the ITRs would behave? Thank you for the feedback, Damien Saucez > > Ross _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
