[RRG] thoughts on the design space 4: encapsulate vs. translate

[Jari Arkko <jari.arkko@piuha.net>]

My other conclusions relate to the choice between encapsulation and 
translation.

First, I think we need to consider this choice in the context of the 
entire functionality, including interworking with the legacy Internet. I 
like the proxy encapsulator (PTR) design, and would far prefer that to 
translation. However, as discussed before its unclear if this is 
deployable due to incentive issues. For the moment, that leaves 
translation as the deployable interworking scheme.

I do not care much whether the upgraded-to-upgrade traffic uses 
encapsulation or translation. That's a detail in many ways.

So for the moment this leaves me with the following "best" design:

1. Employ something like NERD for the mapping table, no caching
2. Identifier spaces are allocated per organization, PI style, and we do 
not attempt to solve the host identifier-locator split
3. Translate or encapsulate when talking from an upgraded network to 
another upgraded network
4. Translate when talking to a legacy network

While this is "best" solution in my today's opinion, the big question in 
my mind is whether it is good enough, and what the drawbacks are. I 
understand that Christian has been making some progress in eliminating 
some NAT effects from translation design when using IPv6. However, how 
significant are the remaining ones? I share the concerns with Brian. 
Also, the entire system has a number of other implications, such as 
effects to referrals, and increased complexity.

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