Robert, I think your classification was useful, but: > Looking strictly at methodologies for change, the available options are: > > 1) 'Replacement.' Tear out the old-style infrastructure and replace it > "in toto". This requires the origin point to do things the 'new way', > the destination point to do things the 'new way', and requires` all > intermediate points to do things the 'new way', as well. > > 2) 'Translation.' Allows old-style end-points to communicate with new- > style end-points *IF* a suitable 'gateway' is interposed "somewhere. > "Network" elements can be either old-style or new-style depending on > which side of the translation gateway they are on. In fact they _must_ > be either old-style or new-style on the appropriate sides of the > gateway. > multiple translations can occur on a path. "old->new-old" is lossless, > "new->old->new" _can_ result in partial loss of functionality. > > 3) 'Encapsulation.' Implement an arbitrary new-style layer 'underneath' > what the end-users see. This preserves/presents the 'appearance' of > the old-style protocol to the outside world, _while_ being free to > do "whatever seems appropriate" in the infrastructure, *without* any > visible impact (except possibly indirectly, in a performance change) > to external users. I think there is something missing here. For instance, as you know we have encapsulation based mechanisms, but we're finding out that even with those, we have to figure out how the "old" and the "new" world should talk to each other. So if 3) really means an overlay, you need to know how to exit from and return to the overlay in order to talk to hosts in the existing Internet.
This leads me to conclude that the real options on the table will in any case include some form of translation. I do not mean translation in the NAT sense here, by the way. What I mean is that A (site) thinks he is talking the new protocol, B (site) thinks he is talking the old protocol, and somewhere in between there a C that converts between the two. For instance, a LISP PTR or Six/One Router 1-1 NAT. Jari -- 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
