On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci <[email protected]> wrote:
> Jeff mentioned for (1) to have the mapping system return a coarse negative > prefix with positive ones which punch holes in negative map-replies. This > will be quite hard since the sender of the negative Map-Reply may not know > all positive entries (since they are spread around and stored in other > map-servers). But the map-server could infer based on looking at the ALT to > find positive entries. So some research can be done on this idea to see if > is tractable. > It would be possible to install shorter negative plus one or more longer positives that are not complete mappings, but "next-hop ms-resolve," which would discard packets to the shorter negative but still be able to punt and do MS query for the possibly-positive part of the address space. If I was the implementer, I would probably then keep count in my Trie to know when a particular branch of the address space cache contains mostly negative entries, which would indicate opportunities for on-demand "compression." Another way to tackle (1) is to have the ITR look at the more-specific > negative prefixes to see if they can be combined into a fewer number of more > coarse prefixes using localized prefix compression. If exact compression can > be done, then do it (meaning their are no positive holes in the compressed > aggregate). If there are holes created, they *could be mitigated* if you > already have a positive cache entry stored because you previously have > encapsulated to the site. But you can't always depend on this ordering to > make it reliable. > I do not understand how this can be beneficial if the MS currently sends negative replies that are the shortest possible prefixes which do not overlap any possible positive mapping. Keep in mind that my understanding of the control-plane remains limited, specifically I am not familiar with how much state is available from the local MS vs what must be retrieved from distant MS. I need to do some homework in this area. > As for (2), we could say, we'll make a tradeoff by saving the cache at the > expense of more load on the mapping system. Well the mapping system (like > DNS) has to be provisioned and capacity planned to handle load for scaling > reasons. So it should also be able to handle DoS load too. And if it can't, > then the DoS load gets dropped (that is the good news). But with every DoS > load that gets dropped there is good load that loses too. So take this with > a grain of salt. > > But if the ITRs only stored positive cache entries, one might think we > would not know when to forward natively to non-LISP sites. Well when an ITR > gets a cache miss, it could send the packet natively as well as send a > rate-limited Map-Request. We do implement very short-lived data-caches so we > can do aggressive rate-limiting. If a Map-Reply is returned, you know the > destination is a LISP site and you cache the positive entry. If nothing > comes back, you continue to forward natively. As I said, this puts more > Map-Request load on the mapping system. > I do not understand how this can be effective. If the ITR does not have a native Locator address for the payload address family, and the site is relying upon LISP, there won't be a way for packets to even reach the "native Internet" for some alternate forwarding to the destination. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
