[ppml] 2005-1 alternatives
Geoff Huston
gih at apnic.net
Wed Apr 20 08:22:17 EDT 2005
At 05:26 PM 20/04/2005, Owen DeLong wrote:
>>But then the duality and implicit tensions of routing scaleability and
>>addresses utility goes back a very long way - the Routing and Addressing
>>Group of the IETF in the early 1990s was an early incarnation of the same
>>set of tensions relating to what makes routing scale vs what makes
>>addresses truly useful and convenient to use.
>
>That is why I am becoming progressively more convinced that we need
>to separate these two functions.
Welcome to a well established area of consideration!
There is a rich body of material that has been generated over as many years
as we've been thinking about packet networking. There are papers dating
back to the early 60's on this issue of what is currently referred to as
the id/loc split, and the topic space encompasses various forms of routing
paradigms, end host paradigms and their various forms of interaction. In
one sense its a wonderfully unconstrained place to think in in the
abstract, and it would be wonderful to see many more folk should be
thinking and working in this area than we have today.
But in practical terms there are a myriad of constraints that needs to be
considered when you come down to the harshness of reality. Personally I'm
of the opinion that its safest, when considering what risks we want to run,
to assume that routing capability and functionality will pretty much
continue for some time yet to be what we see today, and also, for some time
yet addresses will continue to have the semantic overload of entity
identification and location identification. It's this rather conservative
view of the world as we know it that is a valid consideration when looking
at these kind of policy proposals, and yes, there is an amazing level of
tension between maximizing the utility and stability of addresses, and
maximizing the prospects of routing to continue to pass these address
tokens around the network.
regard,
Geoff
More information about the ARIN-PPML
mailing list