[ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6

On 6-dec-2005, at 17:36, Oliver Bartels wrote:

>> To me, it's pretty obvious that if we can have aggregatable PI space,
>> then that's an excellent reason to NOT have non-aggregatable PI  
>> space.

> You may aggregatable PI space if you can convince the router
> manufacturers create and implement a new RFC which adds an
> additional layer for prefix aggregation within the BGP protocol.

I can't imagine what such a layer would look like...

> Geographical aggregation however, is _for_sure_ not the
> solution for the new centrury. Geographical solutions happened
> in the last century.

In IP? Don't think so. If you have pointers, please enlighten me.

> Nowadays carriers use DWDM technology, and yes, a link
> between Frankfurt and London or even New York is cheaper and
> easier to obtain than a link between Frankfurt and Wiesbaden.

Sure. But trying to aggregate on network topology is never going to  
work for two very simple reasons:

1. It changes all the time
2. You can't express a topology with loops in it in an addressing  
hierarchy

The reason to choose geography to aggregate on is not because it is  
somehow magically always the best fit with topology, because it  
isn't. However, it has two very important things going for it: it's  
not subject to change, and it allows for optimization on distance,  
which in turn has the potential to be be good for cost and performance.

Please don't assume you understand my proposal just because it  
contains the term "geography". If you want to know what it entails  
have a look at http://www.muada.com/drafts/draft-van-beijnum-multi6- 
isp-int-aggr-01.txt

> The key issue is whether competing dark fiber or leased line
> carriers are available at a certain location and _not_ the distance
> between those.

Distance is actually very important. It's very hard to do decent high  
speed file transfer on out of the box OSes and applications with high  
delay. Also, it often makes sense to backhaul traffic over SOME  
distance, but that doesn't mean it also makes sense to backhaul it  
over even larger distances. I.e., even if a link to New York is  
cheap, you don't want to go over Palo Alto.

> As routing was not really considered by the designers of the
> IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered
> a lousy solution under this view), we can either live with it
> or give it up. Living with it means providing a solution for
> the PI requesting organisations and waiting for an aggregation
> enhancement of the routing protocols or keep it experimental,
> which probably means: Let it die.

Your conclusions don't follow from your assumptions. Yes, IPv6  
doesn't do anything for routing except allow very large aggregates.  
However, the choice isn't between allowing unlimited growth and  
hoping we can fix it later and not using IPv6, the choice is between:

- Not allowing PI
- Coming up with aggregatable PI of some kind
- Give up and make the exact same mess of IPv6 as we did with IPv4

Today, IPv4 routing works but it has come close to the edge of the  
cliff twice (early 1990s just before CIDR routing tables were too  
large and late 1990s flapping cost too much CPU) and it's still  
pushing towards that edge, which we can't see clearly but know is out  
there somewhere. And that happened in 25 years. We'll very likely  
have to live with IPv6 for much longer than that, so we HAVE to be  
careful from the outset.

Shim6 is coming, aggregation with PI is unexplored, IPv6 is still in  
the extremely early stages, so this is NOT the time to do stupid  
things. If we're still in the same boat in 5 years when we're down to  
18 months of IPv4 addresses, sure, we can revisit this issue. But we  
still have some time. Let's use it.

> Even if the PI question is solved these days, I won't be sure
> if the answer isn't already too late. The market will tell us.

What kind of logic makes this too late?

>> I'd rather have a working internet without PI than a non-working one
>> with it. Nobody can guarantuee that we won't run into trouble with PI
>> so the only way we can be sure we won't have this trouble is to not
>> have PI.

> This argument is unreal, you can stop _any_ project with it,
> in Germany we call it "Vollkaskomentatlitaet" and our country
> suffers a lot from it.

Well, then apply some of that mentality to PI in IPv6 and free it up  
elsewhere.  :-)

> There is simply no way to prove that a given solution won't
> have a side effect.

So because you can't prove that you're right I should just believe  
you without proof?

> If you write: "Nobody can guarantee ..." then I will tell you:

> Nobody can _guarantee_ that your posting by its formating or
> content can't cause a significant harm to an important server,
> cause a worldwide crash of the internet, thus impairs water and
> electricity supply and at the end let the aliens conquer earth.

No, but there's no reasonable scenario that makes this happen either.  
The scenario that de facto unlimited PI in IPv6 will make routing  
tables so large that it becomes problematic in some way or another is  
entirely reasonable, on the other hand.

> More realistic:

> I'd rather like a internet with IPv6 and PI and the very low  
> probability
> of of trouble which can with a high probably be fixed than no real- 
> in-use
> IPv6 because of arguments which request gurantees that can't be
> given for _any_ solution on this planet.

Yes, I've heard it all before. Why don't we work on something that we  
can all get behind? The beauty of my geographical aggregation thing  
is that you still get PI even if it turns out that it doesn't work.  
So you get what you want regardless of who's right. Pretty good deal,  
don't you think?

> Up to now engineers have always proven to find solutions
> for networking problems like the PI issue, thus there will
> be some solution for sure if required.

Sure, we can always implement some kind of aggregation later. This of  
course requires renumbering of all PI space. And isn't the idea  
behind PI space that you never have to renumber out of it...?

> P.s. @RIPE NCC: Question: Is there a practical way to replace the
> slow and cumbersome "consensus" principle of the RIPE by a democratic
> majority vote of the RIPE NCC members to stop further damage to IPv6,
> perhaps with a decision at the next RIPE NCC general meeting ?

Please replace "RIPE NCC members" with "people who have to pay for  
bigger routers world wide" (not just the RIPE region) and I'm all for  
it.

Iljitsch

-- 
I've written another book! http://www.runningipv6.net/