Re: [RRG] On "jack-down" models

["William Herrin" <bill@herrin.us>]

On Sun, Mar 16, 2008 at 5:15 AM, Tony Li <tony.li@tony.li> 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
<victor.grishchenko@gmail.com> 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                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
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