Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Apr 2006 17:07:26 +0200

On 14-apr-2006, at 16:57, Scott Leibrand wrote:

> 60 voted in favor of moving forward with PI.  6 voted against.

Wow, 10 to 1. Amazing.

Even more amazing: 60 people who represent nobody but their own  
paycheck get to blow up the internet.

Where is ICANN when you need it? This little experiment in playground  
democracy has to end before people get hurt.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 14 Apr 2006 11:14:51 -0400 (EDT)

> paycheck get to blow up the internet.

Did you participate in the process?  Even if you can't justify travel to
Montreal, the PPML is wide open.

ARIN doesn't go solely by the vote in the room; they also consider whether
there was consensus on the PPML.

> democracy has to end before people get hurt.

I think the ARIN process is closer to the IETF's "rough consensus" process
than to "democracy".

If you think the PI policy ARIN passed will "blow up the internet", I
would encourage you to participate in drafting policy proposals to help
limit the impact of PI on the routing table.  Bear in mind that we didn't
approve an "IPv6 PI for everyone" policy precisely to avoid "blowing up
the Internet": instead we only extended existing IPv4 policy to IPv6.

As I've written before, I'm attempting to draft an ARIN policy proposal to
ensure PI addresses are assigned in a regular fashion instead of the
random chronological fashion we do now with IPv4.  As you seem to support
that, I would encourage you to help draft such a policy proposal and help
get people to support it.

-Scott

P.S. I don't think we need quite so much cross-posting as this...

---

From: Kevin Loch <[email-masked]>
Date: Fri, 14 Apr 2006 12:51:55 -0400

> Wow, 10 to 1. Amazing.

Sounds like a rough consensus to me.

> paycheck get to blow up the internet.

I find this comment extremely offensive.  Nobody in that room
would have supported a policy they actually believed would blow up
the Internet.  Your implication that the participants were
either uninformed or diddn't care about the consequences is
completely off base.

> democracy has to end before people get hurt.

You would actually prefer ICANN replace the open policy process
of the RIR's?

ARIN participants are simply following the principles the IETF used
to use: rough consensus AND running code.

- Kevin (trimming the cc: list for everyone's sanity)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Apr 2006 19:03:18 +0200

> either uninformed or diddn't care about the consequences is

I'm not saying that these people expected the internet to melt down  
by supporting this policy, but that's exactly the problem. Within the  
IETF, we've been working long and hard to find a way to allow for  
multihoming that we KNOW won't melt the internet, and now just as  
these efforts are getting close to paying off (shim6) a small group  
of people decides to throw caution in the wind and adopt a policy  
that opens the door to exactly the problems the IETF has been working  
so hard to avoid. The trouble is that we don't know for sure that  
doing this will turn out very bad, but there is a risk and with  
something as important as the internet has become, it's a very bad  
idea to take these kinds of risks.

We have two failures: lack of foresight by the 60 people who are in  
favor of this, and a failure to set the I* community decision making  
up in a way that various parts support the same outcome.

>> Where is ICANN when you need it? This little experiment in  
>> playground  democracy has to end before people get hurt.

> You would actually prefer ICANN replace the open policy process

Openness is good, but I'll take good decisions, however they're  
reached, over ones of questionable quality that were reached in an  
open process any day.

> to use: rough consensus AND running code.

Both the IETF and the RIRs suffer from the problem that the people  
that speak up are self-selected. Also, the fact that each RIR comes  
up with its own policies but that the result shows up in routing  
tables world wide makes no sense.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Apr 2006 13:57:43 -0400

At 19:03 +0200 4/14/06, Iljitsch van Beijnum wrote:

>Both the IETF and the RIRs suffer from the problem that the people that
>speak up are self-selected. Also, the fact that each RIR comes up with its
>own policies but that the result shows up in routing tables world wide makes
>no sense.

I disagree with that.

Each RIR is a membership-supported organization, with membership 
largely based upon operational use of the Internet.  By that I mean - 
if you want to operate on the Internet, you need addressing numbers. 
To get addressing numbers you can either buy up the assets of 
something that has pre-RIR space or join an RIR.  The latter entails 
signing up to an agreement, getting space, and paying cost-recovery 
dues (as opposed to "rent").

Don't confuse the RIR "public policy" meetings like the one held this 
week in Montreal with what happens at an IETF.  The *public* policy 
meetings are held to gain access by the general populace to the 
process; these meetings by themselves do not produce policy.  Policy 
within the RIRs are formally adopted only after internal review - 
e.g., in the ARIN region, ratified by the Board who is (all but one) 
elected by designated representatives of the membership.

If 60 people smoking a controlled substance voted for an unwise 
policy I believe "checks and balances" would kick in before something 
regretful happened.  Bad policies may get through - but not because a 
majority of people who happened to find the right hotel room.

Second point, the RIR polices try hard, but don't always succeed, in 
staying away from the routing tables.  Within ARIN, there is a 
special sensitivity to that - the ISP participants try hard to make 
sure that ARIN dictates nothing with respect to the routing table. 
E.g., recently a policy went away from recommending /56 allocations 
to a certain class of customers to saying that ARIN would measure 
utilization (for the purposes of granting more space) base on /56 
deployment.  Any statement regarding how an ISP (LIR) is supFrom [email-masked] Fri Apr 14 14:00:13 2006
Date: Fri, 14 Apr 2006 13:57:43 -0400
To: IETF Discussion <[email-masked]>
From: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: [[email-masked]: PI addressing in IPv6 advances in ARIN]

At 19:03 +0200 4/14/06, Iljitsch van Beijnum wrote:

>Both the IETF and the RIRs suffer from the problem that the people that
>speak up are self-selected. Also, the fact that each RIR comes up with its
>own policies but that the result shows up in routing tables world wide makes
>no sense.

I disagree with that.

Each RIR is a membership-supported organization, with membership 
largely based upon operational use of the Internet.  By that I mean - 
if you want to operate on the Internet, you need addressing numbers. 
To get addressing numbers you can either buy up the assets of 
something that has pre-RIR space or join an RIR.  The latter entails 
signing up to an agreement, getting space, and paying cost-recovery 
dues (as opposed to "rent").

Don't confuse the RIR "public policy" meetings like the one held this 
week in Montreal with what happens at an IETF.  The *public* policy 
meetings are held to gain access by the general populace to the 
process; these meetings by themselves do not produce policy.  Policy 
within the RIRs are formally adopted only after internal review - 
e.g., in the ARIN region, ratified by the Board who is (all but one) 
elected by designated representatives of the membership.

If 60 people smoking a controlled substance voted for an unwise 
policy I believe "checks and balances" would kick in before something 
regretful happened.  Bad policies may get through - but not because a 
majority of people who happened to find the right hotel room.

Second point, the RIR polices try hard, but don't always succeed, in 
staying away from the routing tables.  Within ARIN, there is a 
special sensitivity to that - the ISP participants try hard to make 
sure that ARIN dictates nothing with respect to the routing table. 
E.g., recently a policy went away from recommending /56 allocations 
to a certain class of customers to saying that ARIN would measure 
utilization (for the purposes of granting more space) base on /56 
deployment.  Any statement regarding how an ISP (LIR) is supposed to 
run is being replaced by statements focusing only on what the RIRs 
ought to do, and that is stewardship of the numbers.

I would encourage anyone that is concerned about there being five 
separate RIR policy processes and yet only one global routing table 
to take time to understand the dynamics of the situation before 
drawing conclusions.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Kevin Loch <[email-masked]>
Date: Fri, 14 Apr 2006 14:01:44 -0400

Iljitsch van Beijnum wrote:
> I'm not saying that these people expected the internet to melt down  by 
> supporting this policy, but that's exactly the problem. Within the  
> multihoming that we KNOW won't melt the internet, and now just as  these 
> efforts are getting close to paying off (shim6) 

In case you (IETF) diddn't get the memo, the operational community has
flat out rejected shim6 in it's current form as a replacement
for PI.

This failure of leadership from the IETF to provide a roadmap for a
viable alternative to PI is a factor in the support for going with
the current technology.

- Kevin

posed to

---

From: Kevin Loch <[email-masked]>
Date: Fri, 14 Apr 2006 14:01:44 -0400

- Kevin

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 15 Apr 2006 10:24:03 +0900

Kevin Loch wrote:

>> these efforts are getting close to paying off (shim6) 

> flat out rejected shim6 in it's current form as a replacement

As shim6 effort was initiated by stupid majority ignoring
various operational and other issues that I'm glad it is
treated properly by the operational community.

Steven M. Bellovin wrote:

> Now, if they could qualify the
> locally-unique address with a site prefix it would be easier, but that's
> more or less 8+8 which is what IPv6 addressing should have been from the
> beginning...  I digress -- that issue was hotly debated when IPv6 was
> being created, and though some of us were strongly in favor of it others
> were strongly opposed.

There was debate. But, 8+8 was rejected without any discussion or
reasoning.

						Masataka Ohta

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 14 Apr 2006 20:52:19 -0700 (PDT)

> There was debate. But, 8+8 was rejected without any discussion or

Could someone tell me where I can read about "8+8"?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 14 Apr 2006 21:16:24 -0700 (PDT)

> Could someone tell me where I can read about "8+8"?

http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       [email-masked]
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 14 Apr 2006 21:19:53 -0700

> Could someone tell me where I can read about "8+8"?

a later version changed the name to GSE
   "GSE - An Alternate Addressing Architecture for IPv6"
http://ietfreport.isoc.org/idref/draft-ietf-ipngwg-gseaddr/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Apr 2006 09:17:52 +0200

On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote:

> Wow, Iljitsch, I have never lost so much respect so quickly for  
> someone who was not flaming a specific person or using profanity.   
> Congratulations.

Well, that's too bad. But several years of trying to get a scalable  
multihoming off the ground (flying to different meetings on my own  
dime) where first my ideas about PI aggregation are rejected within  
the IETF mostly without due consideration because it involves the  
taboo word "geography" only to see the next best thing being rejected  
by people who, as far as I can tell, lack a view of the big picture,  
is enough to make me lose my cool. Just a little.

> Back on topic, it is not just those 60 people - the "playground"  
> appears to overwhelmingly agree with their position.  I know I do.

Don't you think it's strange that the views within ARIN are so  
radically different than those within the IETF? Sure, inside the IETF  
there are also people who think PI in IPv6 won't be a problem, but  
it's not the majority (as far as I can tell) and certainly not  
anything close to 90%. Now the IETF process isn't perfect, as many  
things depend on whether people feel like actually doing something.  
But many of the best and the brightest in the IETF have been around  
for some time in multi6 and really looked at the problem. Many, if  
not most, of them concluded that we need something better than IPv4  
practices to make IPv6 last as long as we need it to last. Do you  
think all of them were wrong?

> I am sorry your technical arguments have not persuaded us in the  
> past.  But I would urge you to stick to those,

Stay tuned.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 16 Apr 2006 11:52:28 +0200

> flat out rejected shim6 in it's current form as a replacement

Whatever.  This is all quite silly.  SHIM6 is still speculative in
nature and for the operational community to attempt to quash it is an
exceedingly ridiculous waste of their time.  But heck, at least its
their time and not my time.  As has been shown many times, the Internet
and capitalist economics tend to use the most efficient routes over
time.  The nice thing about the current SHIM6 design is that it's
backward compatible with the rest of the world, so if some SPs don't
like SHIM6 and it turns out to work for enterprises and consumers, tough
noogies.  Otherwise, tough noogies to those who do use it when it
doesn't work. 

As to allocating out PI address space, be my guest.  There would be no
better way for the operational community to assure that they pay for
VERY high end routers for the foreseeable future, and that will line my
and every other CSCO and JNPR shareholders' pockets for a time while
putting out of business smaller ISPs who can't afford such specialized
high end gear (we generally call those people NANOG attendees).  And if
this decision was disconnected from those people then clearly something
is wrong with the RIR governance model (I don't think this is true - I
think the RIRs generally understand this problem).

Eliot

---

From: Joe Abley <[email-masked]>
Date: Sun, 16 Apr 2006 10:03:15 -0400

On 14-Apr-2006, at 14:01, Kevin Loch wrote:

>> I'm not saying that these people expected the internet to melt  
>> down  by supporting this policy, but that's exactly the problem.  
>> Within the  IETF, we've been working long and hard to find a way  
>> to allow for  multihoming that we KNOW won't melt the internet,  
>> and now just as  these efforts are getting close to paying off  
>> (shim6)
>

Given that it's current form is ante-natal, this seems healthy and  
constructive.

I presume you're not saying that the operational community has  
rejected all possible, future alternatives to open slather on PI, nor  
that the vast majority of Internet users who are (for example) not  
served by the ARIN proposal should never be allowed to multi-home.

Joe

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 16 Apr 2006 18:49:03 +0200

[very nice cross posting going on here ;) ]

On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote:
[...
large snip about trying to bash shim6 which is not finalized
yet, thus how can you bash it ?
Note: extra sarcasm included in this post. Eat the eggs with salt.
...]

> Oh, and one thing I should have said last time: Technical arguments  
> are important, but they are only part of the decision process.

In other words: "You are right with your arguments, but I just threw
your args away as they are futile based on the comparison of money
earned this way or the other."...

> People (like me) have explained that the Internet is a business, and  
> in addition to being .. technically unsavory to many people, shim6 is  
> simply not viable in a business setting.

And as you will only care for your business for the coming 10 or maybe
20 years you really can't care what happens to the internet afterward.

The idea of IPv6 is (still not was) to have it around for quite some
time longer than the lifespan of IPv4. Fortunately, the PI thing is far
from the end of the world and will only help catch on, see below.

Of course any vendor will love the idea of having to do another IP
version of course, bring in the cash ;)

> Neither backbone operators  
> (vendors) nor end users (customers) are warming to the idea.  Just  
> the opposite.  (At least in general, the one-in-a-million end user  
> with DSL and cable who likes the idea 'cause he can't figure out how  
> to spell "B-G-P" or doesn't want to pay for it is irrelevant.)

Irrelevant for you as they don't give you money. Indeed, you only look
at your own business interrest (and who can blame you for that ;)
(Once though the internet was there for the masses and not only for the
ones with cash)

> So how do you get a technology widely accepted when the majority of  
> people involved do not think it is the best technical solution?  When  
> the majority of vendors supposed to implement it will not do so for  
> technical -and- business reasons.

There is for you indeed a business reason to not like it: the end-site
won't have any reason to stick to the upstream. Which is indeed a bad
business for many of the 'vendors' you mean.

As Eliot Lear also said very clearly: Thanks for lining the vendors and
all the stockholders pockets ;)

That is in the long run, most likely in the coming 10-20 years the IPv6
routing tables will not have 'exploded' yet, but the folks selling
equipment and having stocks of those venders after that most likely will
have a nice retirement fund. Thanks to you!

Nevertheless, the PI thing is really *not* a bad thing, as it can be
used as an identifier for shim6, which is actually perfect. It just
saves on having to do a complete policy process for getting address
space for this type of usage. But thanks to this, this won't be needed
and thus in the end anybody who can get PI can use a shim6-alike
solution and won't have any problem with the upstream that actually
wanted to lock them in by letting them pay loads for an entry in the BGP
tables.

Thus people voting for PI, thanks for helping shim6 or another solution
in that space, progress a lot :)

And finally on a much brighter note, especially for the shim6 folks:
I know of quite a number of endsites that don't want to use BGP, the
don't care about an entry in the routing tables, but do want to be
multihomed in an easy way and also want to have 1 unique address space
on their local network, but do want to use different upstreams. Shim6
will be perfect for this and thanks to the PI space their is the perfect
identifier.

Greets,
 Jeroen

  (being sarcastic, I guess the amounts of chocolate did it, but hey,
   I have a great excuse being only 7 mins away from the Lindt&Sprungli
   factory outlet, happy easter! ;)

---

From: Kevin Loch <[email-masked]>
Date: Sun, 16 Apr 2006 14:18:10 -0400

Joe Abley wrote:
> I presume you're not saying that the operational community has  rejected 
> all possible, future alternatives to open slather on PI, nor  that the 
> vast majority of Internet users who are (for example) not  served by the 
> ARIN proposal should never be allowed to multi-home.

No, I'm not saying that at all.

This policy change is about creating a viable migration path for non-isp
PI users before the IPv4 panic begins.  Shim6 was seen as not doing that
even if/when it was widely deployed.

A scalable routing architecture that is a suitable replacement for PI 
for end sites would be great.  Please don't give up on that.

- Kevin

---

From: Joe Abley <[email-masked]>
Date: Sun, 16 Apr 2006 16:04:01 -0400

On 16-Apr-2006, at 14:18, Kevin Loch wrote:

>> rejected all possible, future alternatives to open slather on PI,  
>> nor  that the vast majority of Internet users who are (for  
>> example) not  served by the ARIN proposal should never be allowed  
>> to multi-home.
>

Excellent, thanks :-)

> A scalable routing architecture that is a suitable replacement for  
> PI for end sites would be great.  Please don't give up on that.

Joe

---

From: "Patrick W. Gilmore" <[email-masked]>
Date: Sun, 16 Apr 2006 12:10:36 -0400

On Apr 16, 2006, at 3:17 AM, Iljitsch van Beijnum wrote:

> taboo word "geography" only to see the next best thing being  
> rejected by people who, as far as I can tell, lack a view of the  
> big picture, is enough to make me lose my cool. Just a little.

Thank you for believing my opposition of your ideas is simply because  
I "lack a view of the big picture".  Note that it is entirely  
possible I believe the reverse to be true.  Or perhaps you see a big  
picture, and I just see a bigger one.

However, I probably won't lose my cool since, as I stated before, the  
overwhelming majority of people who run the Internet seem to see my  
"bigger" picture.

> radically different than those within the IETF? Sure, inside the  
> IETF there are also people who think PI in IPv6 won't be a problem,  
> but it's not the majority (as far as I can tell) and certainly not  

Yes.

And so does essentially everyone else who runs an Internet backbone.   
These are some of the "best and brightest" in the world, and most of  
them have been around for .. well, 'forever' in Internet terms.

But decision such as these really shouldn't be decided simply because  
someone has been doing this longer.

>> past.  But I would urge you to stick to those,

I'll try.  But honestly, reading the same arguments over and over  
gets tiresome, especially when so many well-qualified people have  
explained the opposing PoV so well.

simply not viable in a business setting.  Neither backbone operators  

So how do you get a technology widely accepted when the majority of  
people involved do not think it is the best technical solution?  When  
the majority of vendors supposed to implement it will not do so for  
technical -and- business reasons.  When the majority of end users who  
are supposed to buy the service will not?

Okie, trick question. :)  You don't.

-- 
TTFN,
patrick

---

From: "Martin Hannigan" <[email-masked]>
Date: Fri, 14 Apr 2006 15:39:36 -0400

> democracy has to end before people get hurt.

I am a member of the ICANN ASO AC and I was there, but I'm not sure
you meant that, and, the ARIN forums are open to all.

The vote was a display to our advisory council to what the constituents
"want".
The ARIN mailing lists get just as much consideration.

Where are you?

-M<

---

From: "Patrick W. Gilmore" <[email-masked]>
Date: Sun, 16 Apr 2006 00:09:43 -0400

I am sorry your technical arguments have not persuaded us in the  
past.  But I would urge you to stick to those, or at least consider  
why we remain unconvinced, rather than devolve into .. whatever that  
post was supposed to be.

-- 
TTFN,
patrick

---

From: Leo Bicknell <[email-masked]>
Date: Sat, 15 Apr 2006 00:23:31 -0400

This message was cross posted to a large number of lists.  I would
like to make the root of the discussion clear, without taking an
opinion.

This link is the original message, best I can tell.  Hopefully from
there each individual on this message can tell how they came to
receive it.

http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00162.html

Please go back to the header as well.  Lists from several different
organizations have been CC'ed, and each will have their own opinion.
All are available on the web.  A well informed reply is the best
reply.

-- 
       Leo Bicknell - [email-masked] - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [email-masked], www.tmbg.org
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Leo Bicknell <[email-masked]>
Date: Sat, 15 Apr 2006 00:23:31 -0400

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Apr 2006 16:40:06 +0200

Kevin Loch wrote:
...
> flat out rejected shim6 in it's current form as a replacement

Kevin, I realise you may have felt provoked by the tone of
some earlier messages, but I must point out that (a) the shim6
work is only at the stage of WG discussion, so "reject" is
really not relevant at this point, and (b) I know personally
of people in the operational community who, far from rejecting
it, are actively working on the specifications.

That being said, constructive technical input from the operational
community is very welcome and is always listened to. Shim6 *is*
listening to it.

> viable alternative to PI is a factor in the support for going with

First of all, "the IETF" is the set of people who choose to work
in the IETF. So if there is a failure, all of us here should look
in the mirror together to find the culprits. Second, I believe that
the failure is much deeper, at the mathematical level - we need an
alternative to the BGP4 model we've been based on for ten years,
and that is a truly hard problem.

Scott Leibrand wrote:
..
 > I agree, especially in the near term.  Aggregation is not required right
 > now, but having the *ability* to aggregate later on is a prudent risk
 > reduction strategy if today's cost to do so is minimal (as I think it is).

I think that's an understatement until we find an alternative to
BGP aggregation. That's why my challenge to Iljistsch was to simulate
10B nodes and 100M sites - if we can't converge a reasonable sized
table for that network, we *know* we have a big problem in our
future. Not a risk - a certainty.

Edward Lewis wrote:
...
 >
 > The debate between 1) what happens to router tables with PI prefixes, 2)
 > what happens when the protocol is crimped into a comfortable-to-operate
 > fashion, and 3) what customers are will to bear, has been raging for
 > more than a year.
 >
 > It's plain to see that PI space threatens to blow up routing.
 > It's plain to see that IPv6 is supposed to allow for end-to-end
 > flexibility.
 > It's plain to see that customers no longer want to be tied to ISPs.

With all due respect to the debates in the RIRs, these three facts were
well known when the multi6 WG was created, four years before the
shim6 proposals emerged. Also, I refer you to a recent message in a
forked part of this thread:
http://ops.ietf.org/lists/shim6/msg01288.html
in which Scott Leibrand nicely positions shim6 and PI as parts of
the overall solution space.

      Brian

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Apr 2006 11:25:19 -0700

> future. Not a risk - a certainty.

The problem with your challenge is the lack of a defined topology. The
reality is that there is no consistency for topology considerations, so the
ability to construct a routing model is limited at best. 

The other point is that the protocol is irrelevant. Whatever we do the
architectural problem is finding an aggregation strategy that fits a routing
system in hardware that we know how to build, at a price point that is
economically deployable. 

As far as I am concerned BGP is not the limitation. The problem is the ego
driven myth of a single dfz where all of the gory details have to be exposed
globally. If we abolish that myth and look at the problem we are left with
an answer where BGP passing regional aggregates is sufficient. Yes there
will be exception routes that individual ISPs carry, but that is their
choice not a protocol requirement. Complaining that regional aggregates are
sub-optimal is crying wolf when they know they will eventually loose to the
money holding customer demanding non-PA space. The outcries about doom and
gloom with PI are really about random assignments which would be even less
optimal. 

The fundamental question needs to be if there is an approach to address
allocation that can be made to scale under -any- known business model, not
just the one in current practice. It is not the IETFs job to define business
models, rather to define the technology approaches that might be used and
see if the market picks up on them. Unfortunately over the last few years
the process has evolved to excluding discussions that don't fit in the
current business models, despite the continuing arguments about how those
models are financial failures and need to change. The point that Scott was
making is that there are proposals for non-random assignments which could be
carried as explicit's now and aggregated later. What we lack is a forum to
evaluate the trade-off's. 

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Apr 2006 15:47:11 +0200

> ability to construct a routing model is limited at best. 

Actually my challenge asked for an assumed geographical distribution
and an assumed set of ISPs and interconnects, I believe. Obviously
one needs to know how robust the result is under reasonable variations
of the assumed topology.

> system in hardware that we know how to build, at a price point that is

Yes, but BGP4 is a surrogate for that.
> an answer where BGP passing regional aggregates is sufficient.

I'm sorry, I don't think I've ever seen a convincing argument how such
aggregates could come to pass in the real world where inter-regional
bandwidth is partitioned at link level or dark fibre level. There just
isn'tany forcing function by which mathematically close prefixes
will become topologically close, because there's nothing that
forces multiple providers to share long-distance routes.

> Yes there
> carried as explicit's now and aggregated later.

I understand his point very well and I'm even in favour of it, because
statistically it can only help aggregation and certainly not damage it.
But I think that without some radically new principle it will at best
very slightly reduce randomness.

     Brian

> What we lack is a forum to

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Apr 2006 16:49:49 +0200

On 21-apr-2006, at 15:47, Brian E Carpenter wrote:

>> If we abolish that myth and look at the problem we are left with

> forces multiple providers to share long-distance routes.

Obviously it would be tremendously helpful if ISP A would handle  
region X, ISP B region Y and ISP C region Z, so it's just a matter of  
dumping the traffic for a certain region with the ISP in question but  
for various reasons this will never work, if only because the whole  
point is that multihomers have more than one ISP and each of their  
connections to their ISPs may be down at any point in time.

Let me try out a new analogy. There are many languages in the world,  
and most international businesses have to be able to work in more  
than one language. Now wouldn't it suck if in a business that has  
customers in 25 countries with 20 languages, EVERY office would have  
to have people that speak EVERY language? Fortunately, although there  
is no fixed relationship between language and geography, in practice  
there is enough correlation so that you can have the office in Sweden  
handle all Swedish speaking customers and the offices in Portugal and  
Brazil the Portugese speaking customers.

Back to networking: send the packets to the place where all the more  
specifics are known. If the place where all the more specifics are  
known is close to the places where those more specifics are used,  
that works out quite well. If the more specifics are used randomly  
all over the place then this technique adds detours, which is  
suboptimal.

>> The point that Scott was

> very slightly reduce randomness.

I guess I'll work on my simulations...

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Apr 2006 11:20:52 -0700

> one needs to know how robust the result is under reasonable variations

I may have missed part of the thread, but the message I was reacting to just
said:
> You'll have to produce the BGP4 table for a pretty compelling simulation
> model of a worldwide Internet with a hundred million enterprise customers
> and ten billion total hosts to convince me. I'm serious.

Let me throw out an example:
With existing IGPs the number of nodes has no impact on the routing system,
but I would interpret the 10B requirement to mean at least 10k subnets, and
more likely 50k subnets per site. This would imply we are working with a
site prefix of /48. Given that today we think we can build routers capable
of 1M entries, it is not much of a stretch to get to 5M by the time there
would be wide-scale deployment of PI. Take this completely arbitrary list as
an example of regional exchange centers:
5 Million Moscow
5 Million Istanbul
5 Million London
5 Million Paris
5 Million Newark
5 Million Atlanta
5 Million Seattle
5 Million San Jose
5 Million Mexico City
5 Million Bogota
5 Million Sao Paulo
5 Million Tokyo
5 Million Beijing
5 Million Shanghai
5 Million Hong Kong
5 Million Singapore
5 Million Sydney
5 Million Bangkok
5 Million Bangalore
2.5 Million Cape Town
2.5 Million Dakar
I am too detached from current cable-heads to know the right list, but the
example list could aggregate your 100M requirement. If you want to fit in
current technology find an appropriate list of 100 cities at 1M each. In the
example case assume 10 inter-regional transit providers, each with 3 diverse
paths to each of the cities in a full mesh; their routers would be parsing
through local needs plus ~70 entries. In the 100 city case it would be local
plus ~310. Either way the 'system' would handle 100M sites in chunks that
are manageable by individual routers. Realistically there would probably be
another 20-50k entries for organizations with enough money to influence some
of the providers and gain a widely-distributed routing slot, but if
individual providers want to distribute more detailed knowledge to optimize
their traffic/circuit mappings, it is their trade-off to make. The rest of
the world doesn't need to know the mess they have made for themselves. The
point is that BGP does not require any router to have full information. That
requirement comes from ego's about who is paying for transit. Making this
example work requires redefining the operational roles of exchange points
and transit providers, as well as a workable settlements standard.

The issue on the table is that we have RIRs trying to create policy to
restrict access to PI space to only the 20-50k deep-pockets with no solid
metric to set a bar; when the reality is that everyone except the carrier
looking for a lock benefits from PI. The challenge is aggregating out those
who only need local independence to foster serious competition. 

> forces multiple providers to share long-distance routes.

There are only 2 forcing functions for any carrier action; regulation &
pain/cost mitigation (well 3 if you count greed as distinct from and the
income side of cost). Why don't carriers carry full real-time explicit
routes for all existing hosts or even subnets today (there are periodic
attempts to push a global spanning-tree)? They have chosen an existing
pain/cost mitigation technical approach known as BGP, which aggregates out
irrelevant details for those outside the local delivery network. Why are we
having this discussion? Because carriers have been allowed to run amuck and
deploy random topology, trading low fiber cost against any concern about the
impact to their routing system (note the worst offenders for routing table
bloat are pushing deaggregates to optimize traffic to their random
topology).  

Regulators -could- put a stop to that, but I would encourage the carriers to
take voluntary action to mitigate the pain. Unfortunately that path requires
setting aside egos and recognizing that random circuits may reduce the cost
of paying a transit provider but they significantly increase another cost.
Compounding the situation is the IETF's engineering mindset that likes the
challenge of finding the complex technical solution, when all that may be
needed is a policy shift that would reduce the topological complexity. There
is a middle ground here where, like local networks announce a prefix
externally, regional networks handle the local details and acquire transit
to get to other regions. The open question is how to define the regions. The
question about which players get which roles is not an IETF concern and will
sort itself out when a cost reducing technology emerges. 

> very slightly reduce randomness.

The principle you are looking for is standardized settlements. We are not in
that business other than to develop any technology that might be needed. In
the mean time if we do not do the work to define structured PI assignments
we will guarantee that the routing system will have to deal with the
randomness that will happen as enterprises force the PI issue. Leaving this
to the RIRs will only guarantee that we have different assignment approaches
in different parts of the world. 

> > evaluate the trade-off's.

So is your favorable perspective shared by the current IESG? In other words
if a bof were proposed on the topic, would it be turned down as out of scope
and in conflict with the currently stated solution in shim6?

Tony

---

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Apr 2006 15:36:43 +0300

Tony Hain wrote:

>If a bof were proposed on the topic, would it be turned down as out of scope
I'm not sure what exact BOF proposal you had in mind, but
the existence of Shim6 WG should not prevent further
discussion. I at least do not take it for granted that Shim6
solves ALL our needs in this space. For instance, it could be that
we need more than one solution for the continuum that
starts from large organizations and continues through
medium and small size organizations to homes and
hosts. Shim6 looks like a very promising solution
for some parts of this continuum, but it is up for
discussion whether something else is needed too.
(Assuming we have a credible proposal for that
"something else", of course -- some of these problems
are very hard.)

--Jari