RE: [RRG] draft-rja-ilnp-intro-01.txt

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: "Tony Li" <tony.li@tony.li>

    > It's a design choice, and it's a very nice and clean one.
    > I asked exactly the same question when I first heard the proposal, but
    > it's grown on me over the years and I'm now convinced that it's in fact
    > a very good choice.

Which implies that it's not a slam-dunk choice, but rather a close one...
It's also worth pointing out that what one would do with a clean sheet of
paper is not necessarily what one would do when one is confronted with
upgrading a massively deployed existing architecture...


To me, one of the 'features' of jack-up is that it does give us an EID in
each packet. Of course, it's only a 32-bit EID (for IPv4), but... If we look
at the problem of upgrading the IPv4 'address' (to use Ran's nice suggestion
of the use of that term for a name with both locational and identification
semantics), one obvious practical/deployable choice is to move one of those
two functions out first, thereby making the deployment path more tractable.
And moving out identification requires changing all the hosts... which is
what has led me (after flirting with moving out identification first) back to
where I started in the 80's, which is moving out the location functionality
first.

So if we move location out to new namespace, with a jack-up design, once we
have that established, then with that as a new fixed point (i.e. something we
can rely on for continuity) then we can go back to looking at deploying a new
namespace for identification, one which is more precisely suited to what such
a use would want to see.

	Noel

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