[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PI/metro/geo [Re: The state of IPv6 multihoming development]
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
Iljitsch van Beijnum wrote:
>
> On Mon, 28 Oct 2002, J. Noel Chiappa wrote:
>
> > 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.
>
> 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