[ppml] Policy Proposal 2005-1: Provider-independent IPv6
Vince Fuller
vaf at cisco.com
Thu Apr 27 20:27:28 EDT 2006
> [Apologies to those on the list that feel I have exceeded my posting limit
> for the day. I could not let this stand without response.]
As I could not. But I plan this to be my last posting on this topic as
either I will have pursuaded others to more clearly consider the big issues
here or I won't by now.
>> I ask myself "oh why do I waste keystrokes on this?" but then I do it
>> anyway. If it is true that one definition of insanity is doing the same
>> thing over and over while expecting the same result, then I should really
>> stop trying to provide intelligent explainations about scaling issues on
>> NANOG...
>>
> I believe you mean expecting different results.
Indeed. That's what I get for posting to ppml or nanog under the influence
of six days' cumulative sleep deprivation caused by a 10-hour jetlag...
Interesting that the mind's ability to use context to see what it expects
to see rendered useless any proof-reading of this paragraph.
> My operational experience includes senior backbone engineering at a
> number of different ISPs, ranging from Netcom (mid-size, national at the
> time) to ConXioN (small start-up at the time) to Exodus (mid-size, national
> when I started and large international for a significant portion of the
> time I was there). I also have substantial enterprise and small business
Interesting. Where you at Exodus during the "great GTEI-Exodus de-peering
incident"? It contained an excellent anecdote on the subtlety of grasping
large network scaling issues.
At the risk of a little digression and reveleation of a tiny bit of
confidential information that two companies that no longer exist can't
really care about any more... Back in the 90s, GTEI was one of the
top-tier "backbone" ISPs. Exodus, principally a hosting company, wanted
settlement-free "private peering" and GTEI said no based on measurements
that showed that Exodus sent far more traffic to GTEI than the reverse.
This was one of the early uses of traffic ratios to call for settlements;
the rationale was that traffic exchange via "shortest exit" caused the
receiver of the traffic to bear a much larger share of the cost than the
sender so when traffic was severely out of balance, a settlement was in
order (the debate over this continues to this day and is one of the
underlying *technical* rather than policy/anti-competitve around to "net
neutrality").
Anyway, Exodus proposed that instead of paying a settlement, it instead
do "best exit" (sometimes called "cold potato" routing) toward GTEI. GTEI
technical staff initially rejected this because the only way to implement
this in the routing system is to de-aggregate and send MEDs, which is
fundamentally non-scalable. Management types overruled these objections
and insisted that an experiment be tried, limiting the routing scope of
the more-specifics by marking them "no export" to address the concern of
non-scalability. Technical staff raised an additional concern that doing
this created inconsistancies in the routing system which could only lead
to bad things happening, but the experiment was tried anyway. What
happened? Within a day of implementation, these concerns proved well-
founded: more-specifics leaked and Exodus became a transit path for some
high-profile GTEI customers. Needless to say, the experiment was quickly
terminated.
Again, I offer this description not to imply any incompetence or malfeasance
on the part of any of the parties involved... just to show that it is very
difficult to understand and appreciate big network scaling issues.
> I don't think that the IETF acted in bad faith, and, I'm not trying to make
> any such accusation. I do think that the IETF failed to deliver a scalable
> routing solution and continues to focus on dead-end paths that do not
> offer any possibility of real solution.
Not bad faith but egos and expedience got in the way of hard problem solving.
We can't afford for that mistake to go un-corrected.
Oh well. My last post. Time to sit on planes for 20+ hours.
--Vince
More information about the ARIN-PPML
mailing list