Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development]

From: "J. Noel Chiappa" <[email-masked]>
Date: Mon, 28 Oct 2002 11:01:48 -0500

> From: Brian E Carpenter <[email-masked]>

    >>> E.g. if a (large enough) bunch of customers band together and create
    >>> an exchange, which buys service from multiple ISP's, and which is
    >>> given an address which is visible over the same scope as those ISP's,
    >>> and the customers are addressed as part of that exchange, you meet
    >>> the policy goal (being able to change providers) *without* so-called
    >>> "PI" addresses. But the addresses are still connectivity-based.

    > The problem with this (and the reason I have serious doubts about
    > Tony's PI proposal, and all geographical proposals going back at least
    > to Bill Simpson's metro proposal years ago)

Well, you usefully point out that all geographical proposals basically amount
to the proposal to create exchanges! :-) At least, if the routing is to remain
functional!! :-) :-)

    > is
    >  There is no economic reason to create such an exchange.
    > If we could get past that, of course it works.

Ah. You misunderstood the point of my comment, which was not to advocate the
creation of exchanges, but solely to point out that the terminology of
"provider-independent" is not technical terminology, but rather
economic/policy terminology.

In other words, there are addressing scheme which are "provider-independent"
but which differ in extremely important technical ways from the PI addresses
proposed by various people.

The important division in addressing schemes is between "connectivity-based"
and "non-connectivity-based", and it occupies the same place in networking
discussions as the division between "second-law-machines" and
"perpetual-motion-machines" does in engine discussion.

There are many useful finer subdivisions of the "connectivity-based" class
(e.g. hierarchical, provider-dependent, exchange-dependent, etc - some
orthagonal to each other), just as there are many useful finer divisions of
the "second-law-machines" class. However, at least in discussion of engine
designs one normally doesn't have to spend a lot of time discussing
perpetual-motion machines; everyone involves understands that although that
is the most fundamental division, the second class isn't worth discussing,
and not a lot of time gets spent discussing things in that division.

One day the networking world will get there too, and the only discussion of
routing-names (i.e. those names/identifiers/whatever which the routing
calculations use - addresses, in the IPv4/6 architecture) which people will
bother with are the "connectivity-based". I'm not holding my breath.

If people don't like some of the properties that being connectivity-based
induces in routing-names, then the answer is simple: define another
namespace which has characteristics you like better, and map back and forth
between the two.

If the price of that is too high, then you just have to deal with the
hassles of connectivity-based names, just like we have do live with the
hassles of friction, entropy, etc.

	Noel

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 28 Oct 2002 09:48:48 -0800

J. Noel Chiappa wrote:
> Well, you usefully point out that all geographical proposals 
> basically amount to the proposal to create exchanges! :-) At 
> least, if the routing is to remain functional!! :-) :-)
> 
> 
>     > is
> Ah. You misunderstood the point of my comment, which was not 
> to advocate the creation of exchanges, but solely to point 
> out that the terminology of "provider-independent" is not 
> technical terminology, but rather economic/policy terminology.

We don't need to create exchanges, there are already over 200 located in
the global population centers. The economic incentive that is missing is
the motivation for providers to connect to them. Routing table growth
might become enough of an economic burden to cause that. Unfortunately
we are paralyzed by the fear that it will, while refusing to pay what it
will take to avoid it.

Tony

> 
> In other words, there are addressing scheme which are 
> "provider-independent" but which differ in extremely 
> important technical ways from the PI addresses proposed by 
> various people.
> 
> 
> The important division in addressing schemes is between 
> "connectivity-based" and "non-connectivity-based", and it 
> occupies the same place in networking discussions as the 
> division between "second-law-machines" and 
> There are many useful finer subdivisions of the 
> "connectivity-based" class (e.g. hierarchical, 
> provider-dependent, exchange-dependent, etc - some orthagonal 
> to each other), just as there are many useful finer divisions 
> of the "second-law-machines" class. However, at least in 
> discussion of engine designs one normally doesn't have to 
> spend a lot of time discussing perpetual-motion machines; 
> everyone involves understands that although that is the most 
> fundamental division, the second class isn't worth 
> discussing, and not a lot of time gets spent discussing 
> things in that division.
> 
> One day the networking world will get there too, and the only 
> discussion of routing-names (i.e. those 
> names/identifiers/whatever which the routing calculations use 
> - addresses, in the IPv4/6 architecture) which people will 
> If people don't like some of the properties that being 
> connectivity-based induces in routing-names, then the answer 
> is simple: define another namespace which has characteristics 
> you like better, and map back and forth between the two.
> 
> If the price of that is too high, then you just have to deal 
> with the hassles of connectivity-based names, just like we 
> have do live with the hassles of friction, entropy, etc.
> 
> 	Noel
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 29 Oct 2002 00:07:45 +0100 (CET)

> hassles of friction, entropy, etc.

So what is it that makes "connectivity-based" names so good and
everything else so bad? Unless I'm much more mistaken than I thought
possible, the relationship between a connection and a name/address is
purely contingent. Things would be different if routing were
hierarchical, which it isn't. Let me draw an ASCII picture:

	     G
	    / \
	   /   \
	  E     F
	 / \   / \
	A   B C   D

If the only way to get from A to D is A -> E -> G -> F -> D everything
gets very simple and very scalable. However, not only does this not
match the way things work--it doesn't even come close. There is
absolutely no way to make real-world interdomain routing fit inside a
hierarchy.

In reality, each AS occupies a place at the top of the hierarchy. Some
ASes have many lower layers inside, some don't. But if an AS could be
hidden completely behind another AS, the AS wouldn't qualify for an AS
number and not exist in the BGP view of the world to begin with.

This means we have to live with a very large number of prefixes in our
routing tables. Fortunately, a single big thing can usually be split
into a larger number of small things to make it more manageable. Four
smaller routers that handle 2000::/5, 2800::/5, 3000::/5 and 3800::/5
respectively, are probably cheaper than one big one that handles
2000::/3. Now if a multihomed customer of two ISPs with address range
3333:abc:def::/48 were somehow to connect to routers that handle the
3000::/5 portion of the routing tables at both her ISPs, that would
certainly make things easier. And if the 3000::/5 routers of those ISPs
could talk to each other, that too. It wouldn't be necessary per se,
just easier.

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Oct 2002 16:29:52 +0100

Iljitsch,

Noel has already answered, but I would like to add that we know the
routing structure will be flat at some level. However, to get to the
ten billion node Internet we need to plan for, we need aggregation
of addresses much deeper in the topology than we have it today -
let's think in terms of 10000 subnets represented by one route,
for example.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 29 Oct 2002 17:07:31 +0100 (CET)

> let's think in terms of 10000 subnets represented by one route,

Any particular reason for the 10 billion figure?

My provider-internal solution (see draft) doesn't scale to quite this
level, but I believe it will buy us more than enough time to work out
all the kinks in one or more multi-address solutions. I would very much
appreciate some feedback that isn't just geo-allergy.

Iljitsch van Beijnum