On Tue, Jul 26, 2011 at 6:38 PM, Noel Chiappa <[email protected]> wrote:
> > For returning packets there is no need to do DNS lookups but if I have > > understood LISP correctly the cITR needs to do MS lookups so that > > returning packets gets routed back to the residences. If the cITR uses > > only one MS server there will be intensive traffic between the cITR and > > the MS server > > As mentioned above, I favour some sort of 'piggybacking' (an class of > optimization used in a number of places in LISP) to prevent this by > 'pre-loading' the mapping into the cITR's cache, although I'm more concerned > about delay/etc than the server load (although that of course is an issue > too, but only in some circumstances, like the one you outline, whereas delay > is always an issue). I agree with you, it would be nice to be able to pre-load the database to the cITR, the delay is the bigger issue since for the returning traffic is "one to many sites" lookup and hence the cache mechanism might not be as efficient as in DNS. But taking that approach, the mapping system would look more like BGP than DNS. > > > The major difference with today's architecture is that there is no need > > to do a lookup in DNS for returning traffic > > Correct - this is the big architectural difference, hence my desire to get > rid of the mapping lookup in the reverse direction. (I had a great way to do > this in a secured way in CONS, but alas we aren't using CONS.) > > > If the cITR cache doesn't scale enough and I would prefer to add a > > second cITR .. How do I ensure that the returning packets are routed to > > the correct cITRs? > > This is a great question/engineering issue, and one that has been extensively > discussed in the past. There is no great, easy, solution. Even if one can > provide the 'return' mapping to the ingress cETR (above), what happens if > that's not the same box as the cITR? One either i) has to work out a way to > make sure it is the same box (not trivial), or ii) pass the mapping to the > box that will be the cITR (not trivial), or iii) give up on optimizing out > the lookup cycle in the return direction (not acceptable, IMO). In other > words, the engineering details of large sites remain to be fully worked. > Think we have to live the lookup cycle in the return direction so that uRPF can be used to prevent DoS and cache trash. But it might cause delays for returning packets due to an event - this "ticket sale" event can be created by a botnet admin if he has enough clients behind rITRs and directed towards any content site. Thus the lookup cycle for returning traffic is not only an issue for larger content sites but also for all business critical content sites (today multi-homed content sites). The risk of lookup cycle delay can be mitigated if the server stack is upgraded, if that would be possible then the content site admin has a choice. Patrick _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
