On Fri, Jun 27, 2008 at 01:17:09PM -0400, Noel Chiappa wrote: > My point was that, if my thinking is correct (and if it's not, can someone > please point out where I've gone wrong), it's not reasonable to > simultaneously say 'I want location/identity separation' and also say 'I > don't want to change existing host software' and 'I think a big mapping > database is not feasible'. If you want the first, one of the next two _has_ > to give; the only question is _which_.
I agree. The first statement implies either host changes, or some sort of network wide mapping. As an operator, I'm feeling a bti stuck by this quandry, though. I definitely want the loc/id split, since that seems like the most direct way forward to avoid the scaling problem. On the other hand, large scale host changes seem difficult and tiem consuming. And I have serious concerns about how we move from the current routing regime to something that depends on a network wide database. If you operate a service where reliability and reachability are key, that transition period could be extremely painful, and may not be possible without further impact to the scaling problem (by carrying a full set of conventional routes *and* handling some sort of map-and-encap protocol at the same time, for example.) Perhaps it's a lack of imagination, but I seem to find myself in a maze of twisty passages every time I head down this path. I'd like to explore scaling alternatives for the routing system that aren't tied to loc/id splits, but I have thus far failed to figure out what that might possibly be. I think you nailed it in terms of the dependencies. I just don't like them. -David -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
