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



More information about the ARIN-PPML mailing list