> From: Patrick Frejborg <[email protected]>
> But taking that approach, the mapping system would look more like BGP
> than DNS.
Yes and no. For _most_ sites, no, since their access patterns (even for
servers) are to a limited share of the Internet, therefore much less than a
full table. Also, BGP (like any 'push' system) distributes _everything_ to
_everyone_, regardless of whether they need it or not. Any data at any ITR
(even if it's a cITR at a content provider, with lots of data) is there
because it is _actually going to be used_.
Yes, for cITRs, it will be a lot of data. But TANSTAAFL - separating location
and identity is going to have some costs, to go along with all the benefits
it provides. And an alternative 'clean-sheet' architecture might have
slightly better distribution of those costs (i.e. without point loads such as
a cITR), but then you have the 'cost' of a forklife upgrade to everything in
the network - and we know from experience that doesn't succeed very well. I
do expect people will come up with some way of partitioning the mapping state
to get rid of large point loads (e.g. through parallel cITRs at large sites).
Let's not forget that _any_ location/identity separation system (which there
is general consensus we have to have) is going to have to have roughly the
same amount of mapping state, so it's not like there's some magic dust that
can make the problem go away entirely...
> Think we have to live the lookup cycle in the return direction so that
> uRPF can be used to prevent DoS and cache trash.
I don't understand the issue there, but in any case, speaking of the need for
a lookup cycle, I do think that there is almost certainly a way to do some
sort of piggyback to cut out the lookup cycle _delay_ (although of course the
return mapping will have to be provided to the server ITR in some manner).
It's just a matter of working out how to do it...
>> give up on optimizing out the lookup cycle in the return direction
>> (not acceptable, IMO).
> the lookup cycle for returning traffic is not only an issue for larger
> content sites but also for all business critical content sites
No disagreement - hence my statement that "[not] optimizing out the lookup
cycle in the return direction [is] not acceptable, IMO".
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
