On Sun, Mar 16, 2008 at 5:15 AM, Tony Li <[EMAIL PROTECTED]> wrote: > As part of our original charter, we accepted as axiomatic that the > overloading between the locator and identifier namespaces was harmful.
Hi Tony, I wasn't around when the group was chartered, but my knee-jerk reaction to this statement is: have we learned nothing from IPv6? 9/10ths of IPv6's deployability problem stems from the insistence on using new number resources instead of extending the old ones. Deploying the new number resources is proving to be a much harder and more expensive problem than developing and deploying the protocol software. The effect on IPv6's deployment has been exceptionally harmful. > The logical alternative to this is to continue to use addresses, but instead > of as identifiers, to retain them as locators. I respectfully submit that the most logical course of action is to retain EIDs as identifiers but within upgraded parts of the system, restrict which EIDs are able to take on the task of both identifier and locater. I'm very curious what desirable functionality that would exclude and what undesirable functionality such an approach would require. I'm not seeing it off the top of my head. On Sun, Mar 16, 2008 at 10:50 AM, Victor Grishchenko <[EMAIL PROTECTED]> wrote: > It seems, you exclusively assume incremental as-an-upgrade > deployability. There are also other scenarios. Take Ethernet, > for instance. It incrementally ate a lot of competing/legacy > technologies without compromising own architectural purity. Victor, Ethernet was usually the first LAN technology deployed at a location. It tended to arrive late at locations which had something else first and faced great resistance where the incumbent deployment was large. Situationally, we're talking apples and oranges. Our routing solution will almost always have to either displace or supplement an incumbent technology. If the former, it had better be able to do so in a manner compatible with the deployer's neighbors, clients and suppliers. If the latter, it had better offer enough new capability to merit the additional expense. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- 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
