Olivier,
1. Employ something like NERD for the mapping table, no cachingBy doing this, you assume that the only benefits of a mapping system is to reduce the number of prefixes carried on core routers. In this case, a static mapping system could be acceptable, but a mapping system can offer many more benefits than simply improving the scalability of the core routers. A dynamic mapping systems can allow sites to do much more, see :http://inl.info.ucl.ac.be/publications/evaluating-benefits-locatoridentifier
I agree that we want more than merely the reduction of the # of prefixes. However, the question is what parts of that "more" rest on the mapping system and what is in the responsibility of the two networks talking to each other in an end to end fashion.
I a sense, I feel that we are talking about what information should be cached. What I was saying above was about the ID->LOC mapping table. I agree that a network A and network B need more information than this in order to do, for instance, failover and traffic engineering.
But does that information have to be in the mapping system? It is something that the two ends can also establish by themselves. In the process of discovering this information they may some cached state. For instance, one of the two edge routers is actually down.
This will also have similar effects as full-blown caching of all mapping information. You might lose a packet if one of the chosen edge router was down. You might have delay if you sent the packet to a non-preferred router. We need to find out if the effects of this type of caching are harmful, too. But I would expect the effects to be much less significant than in wholesale caching. (But if the effects turn out to be harmful, then we face a difficult problem of creating a large distributed database that also needs to change at a fast pace.)
I'm not sure I understand what you are saying above. Can you elaborate this a bit?and we do not attempt to solve the host identifier-locator splitI think that in some environments locators would be attached only to routers while in other environments locators would be attached to (at least some) hosts. The architecture should support this, at least in the long term.
Jari -- to unsubscribe send a message to rrg-request@psg.com 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