Subject: RE: The state of IPv6 multihoming development

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 22 Oct 2002 12:47:05 -0400

> From: "Tony Hain" <[email-masked]>

    > Iljitsch van Beijnum wrote:

    >> 4. Work on geographical aggregation

    > To which I submit

Let's try this one more time.

An "address", as used in the IPv4/v6 architectures, is a name that (among
other functions) specifies *where* that entity is in the network: i.e. where
it is attached to the network's connectivity topology. In other words:

"geographical address" ->
"geographical topological-location-name" ->
"connectivity-independent topological-location-name" ->
"topological-location-independent topological-location-name".

The latter is, rather obviously, a paradox. Q.E.D.

While I'm at it, I rather admire the skilful political spin displayed in
naming them "provider-dependent" and "provider-independent" addresses,
thereby completely obscuring the underlying technical issues, and making it
seem like it's purely a policy issue, one in which the large providers are
out to screw the customers. Maybe y'all should introduce terminology of
"RIAA-addresses" and "Microsoft-addresses", as alternatives for
"provider-dependent addresses", for extra PR bang.

If you want technically accurate terminology, as opposed to politically
accurate, call them "connectivity-dependent" and "connectivity-independent".

	Noel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Oct 2002 19:04:56 +0200 (CEST)

> Let's try this one more time.

Do you think one more time is all it will take...?

> it is attached to the network's connectivity topology.

I wouldn't call an address a name, but who cares. The real problem is
that you tie addresses to the topology. Why? Obviously there is some
hierarchy so the two can't be completely seperated, but when looking at
the AS level there is absolutely no relationship between an AS, the
addresses it uses and its place in the network topology.

> In other words:

> The latter is, rather obviously, a paradox. Q.E.D.

Ok, now I have to say I don't quite follow your permutations, but if
this is such a paradox, how come it has worked for years for E.164
addresses?

Iljitsch

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Oct 2002 13:08:35 -0700

J. Noel Chiappa wrote:
> ...
> An "address", as used in the IPv4/v6 architectures, is a name 
> that (among other functions) specifies *where* that entity is 
> in the network: i.e. where it is attached to the network's 
> connectivity topology. In other words:
> 

The missing link of the chain is that the provider-independent name ends
up being connectivity-dependent by aligning the scale of abstraction
such that the connection falls within its boundary.

> 
> While I'm at it, I rather admire the skilful political spin 
> displayed in naming them "provider-dependent" and 
> "provider-independent" addresses, thereby completely 
> obscuring the underlying technical issues, and making it seem 
> like it's purely a policy issue, one in which the large 
> providers are out to screw the customers. Maybe y'all should 
> introduce terminology of "RIAA-addresses" and 
> "Microsoft-addresses", as alternatives for 
> If you want technically accurate terminology, as opposed to 
> politically accurate, call them "connectivity-dependent" and 
> "connectivity-independent".

There was no attempt to make this a political argument, in fact it is
more accurate than connectivity-*. The current policy says customers get
their prefix from their provider so that it aggregates, therefore it is
provider-dependent. End sites are looking for a mechanism that allows
them to decouple their prefix from any specific provider, therefore it
is provider-independent. You are correct that when the bits hit the
wire, connectivity is the thing that matters, but that is what the
prefix exchanges in BGP tape back together. If a connection falls
outside the scope of an available aggregate, it will flatten routing up
to the next available level of aggregation. There is no magic here, as I
am sure you are well aware.

Tony