[ppml] 2005-1 or its logical successor

Tony Hain alh-ietf at tndh.net
Wed Nov 2 00:52:15 EST 2005


Paul Vixie wrote:
> # > you're still basing assertions on a premise i've disputed, ...
> #
> # The assertion is based on the fact that there are a limited number of
> fiber
> # runs under the oceans.  Yes that number is more than 1, but it is not
> # numbered in the thousands, and will continue to be limited over time due
> to
> # costs.  There is no reason for a network in New York to know the gory
> # details of the traffic engineering in Beijing, any more than the
> networks in
> # Beijing need to know the details of local delivery in New York.
> 
> this is mind boggling.	 the routers aren't at the landing stations,
tony!

That is a business decision, not a technical one.

> and in some years, the only way to get IP from one part of europe to
> another
> or from one part of asia to another or from one part of south america to
> another was through new york or palo alto or miami.  

Those were frequently a political decision, and in other cases business
ones. There could have been interconnection in those places to avoid routing
through remote hops, but the technology allowed them to run long paths so
the rest of the world had to deal with it.

> there is a HUGE need for
> the folks in beijing to be able to access and traverse the local IP market
> in new york, and vice versa.  and in my view, this is a trend, one that
> will
> accelerate and one that is good for the internet and for every user and
> every provider of internet services.

Actually the long term trend is the other way as there are more local
exchanges and peering interconnects now than 10 years ago. I can't speak to
any recent trend that might be doing traffic engineering around the local
options, but the 'need' has more to do with policy than technology.

> 
> # The entire concept of a global DFZ with detailed traffic engineering
> # overlays has been about raising the bar to prevent entry by new players.
> 
> i hold the exact diametrically opposed view.  the global DFZ is the only
> think preventing us from paying $10000/meg to one or three huge providers.

We don't need a global DFZ to accomplish the bypass you are alluding to.
That is just cheaper than the interface count it would take to run an N-way
mesh. These are all just economic trade-offs here because we have the
technology to do things differently if we want to. The bottom line is that
we don't want to either due to fear of extortion, or just loss of control. 

> 
> # That approach is not required for bit delivery to work.  Bit delivery is
> # possible using transit providers interconnecting exchange based
> aggregates,
> # and that would be no more brittle than what we currently have.
> 
> that's soviet-style central planning thinking you've got going there.
> yow!
> sure, you could rebuild MILnet and maybe NSFnet or Internet-2 that way --
> but
> a global IP economy will be organic and unplannable.  paraphrasing
> padlipsky,
> the territory is under no obligation whatsoever to conform to your map,
> sir!

True, though if things get too out of hand the bunch at the UN has the
regulatory power to encourage conformance. I am not suggesting we should
allow things to get there, just noting that there is a boundary condition in
that direction. 

> 
> # ... Allowing everyone to express their policy
> # in the global view just adds to bloat.
> 
> i don't like the bloat either.  we wouldn't need nearly as many prefixes
> if
> our edge could be more dynamic.  (once again i lament the death of
> A6/DNAME.)

>From my perspective A6/DNAME was not as technically flawed as the fragile
DNS infrastructure that it relied on. The biggest problem with A6 is that it
seriously stresses the DNS infrastructure as compared with AAAA, and the
only reference experience looked more like AAAA than A6. 

In any case it is not dead so much as parked waiting for someone to show
that it won't break everything.

> 
> however, if the edge is to be static, it will be huge.  that's the game.
> 
> # > but we digress.
> #
> # I agree with your goal, but recent WiFi efforts show that no matter how
> lame
> # the deployments by industry are, as soon as a city steps up for the good
> of
> # their citizens those lethargic providers will cry foul.
> 
> let 'em cry.  my money is on gavin.  though san francisco needs an
> internet
> exchange, and IP providers applying for any kind of permit or license
> should
> be required by the city to exchange local routes MLPA-style with other
> ISP's.
> (why should i have to use a bicycle messenger rather than FTP to ensure
> that
> my bits don't leave town on their way to someone else in the same city?
> and
> why should i have to pay the same rate for local delivery as long
distance,
> especially when transporting terrabytes per day?)
> 
> but we digress.

Your arguments are fundamentally opposed to each other here. This comment
says regulation is appropriate at a city scale while the one above about
intercontinental transit should not be regulated. Why shouldn't there be a
global requirement for exchange based peering on whatever scale makes sense?
Should there be a single exchange for each of San Francisco, San Jose, and
Oakland, or one that covers the entire Bay Area, or California? My argument
is that the cost of running independent exchanges and transit should be
weighed against the cost of routing impact within that area. If local
routing scales then deploy one regulated exchange; if it doesn't then deploy
more until you fit within what routing can support. The current system looks
more like an N-way mesh laid over a shared routing table than anything else.
In any case the key ingredient here to mask out the mass of PI space to end
sites is that a regulator said 'MUST PEER'. There is nothing magic about a
city doing that vs. a national government or the UN.

> 
> # I don't mean to act as if the boundaries are known.
> 
> well, but, you are.  acting that way, that is.

I will try to act differently, but it is hard to teach an old dog new
tricks.

Tony




More information about the ARIN-PPML mailing list