Subject: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Jun 2004 20:30:34 +0900

Kurt Erik Lindqvist;

>>If you estimate that you will continue to be very small, you could use
>>a /40 or such from one of your upstream ISPs (which is a problem 
>>*today*,
>>as there are not enough upstream ISPs, indeed).

> This doesn't fly. He can't set his own routing policy and he can't 
> multihome.

Kurt, as I made presentation in front of you and Brian
Carpenter at multi6 WG meeting of IETF58 in Minneapolis
on Nov. 2003, it is possible for a small ISP delegated
address blocks from multiple larger ISPs and can still
have its own policy.

Since then, you made no counter argument against my
presentation that it is your fallacy to say things
against the presentation.

For those of you who are not familiar with my (expired) draft
used at the meeting, it is available at:

   http://www.watersprings.org/pub/id/draft-ohta-multihomed-isps-00.txt

The interim conclusion of the draft is:

   Thus, it is not essential that ISPs have their own TLAs.

> If he changes the single upstream his customers needs to 
> renumber.

If one changes homing, one needs to renumber, of course.

But, it has nothing to do with multihoming or hierarchical
ISPs.

Just as we shouldn't discourage customers change ISPs, we shouldn't
discourage ISPs change upper level ISPs.

>>So shall we abandon it?

> Yes.

No.

>> In favour of *what* to replace it?

> RIR membership.

No. It is proven not to scale.

Does it mean that it is beneficial for you if RIRs have more
power even though it sacrifices ISPs and users of the Internet
by requiring routers with a lot more routing table entries
than necessary?

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Jun 2004 21:18:05 +0900

> "Proven"?  When, where, by whom, based on what data?
> 
> There are less than 10.000 LIRs in existance today, all RIRs combined.

According to my upper bound, it's already unnecessarily too large.
 
> 10.000 routing table entries is something far below the near 140.000 we 
> have today in IPv4.  While I'm seriously unhappy with the 140.000 IPv4
> routes, it *does* scale up to fairly insane numbers.

Of course, you can have as many routing table entries as you want,
as long as backbone routers, speed of which degrade as their routing
table bloat, have large enough routing table.

However, routing table does cost. High speed memory for backbone
routers costs a lot.

The cost must be paid by ISPs and, then, by users.

If the size of global routing table is limited by a hard upper
bound, it simplifies the design of routers a lot (you can put
a backbone router (or many of them) with a global routing table
in a chip), reduces cost of routers a lot and increases speed
of routers a lot.

Note that, for scalable (thus, end to end) site multihoming properly
work, all the sites are required to circulate global routing table
within the sites.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 22 Jun 2004 14:15:52 +0200

The following is explicitly not written as co-chair of the IETF multi6 
WG.

> Carpenter at multi6 WG meeting of IETF58 in Minneapolis

I think I have seen close to 40 presentations that all would solve the 
multihoming problem one way or the other, or at least parts of it.

> address blocks from multiple larger ISPs and can still

It's possible for a small ISP to get several blocks from their 
upstream, route them inside their network and assign each of their 
customers with an address out of each of those blocks. Does it scale? 
Nope. Can it handle failures in the upstream? No. Etc.

> against the presentation.

There are several of the proposals in multi6 that have never received 
comments, nor support of any kind.

>    Thus, it is not essential that ISPs have their own TLAs.

Your document does not address the criterias for being classified in a 
particular category. It does not address what would happen if an ISP 
grow, get's split/divided. It does not address what the financial 
models for transit would be. It does not address the non-balance of 
local vs global traffic coverage. It does not take into account the 
current peering economics of the Internet. So it's really hard to say 
anything regarding it.

> If one changes homing, one needs to renumber, of course.

Which is a limiting factor that I think you will that customers will 
find unacceptable.

> discourage ISPs change upper level ISPs.

Having to renumber when chaining ISPs is not to discourage _change_ of 
ISP. It's to discourage signing up with that ISP in the first place.

> No. It is proven not to scale.

In what way?

> by requiring routers with a lot more routing table entries

I am not following this. In what way would the RIRs get more "power"? 
The policies of the RIRs is set by the RIR community. We are having a 
lot more routing entries today than we need to, and people seems to 
think it is a good idea. Actually it is today used to implement 
policies that follow requirements set by users to their ISPs. Users 
that pay to get that policy.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Jun 2004 21:53:52 +0900

Kurt Erik Lindqvist;

> multihoming problem one way or the other, or at least parts of it.

40?

Below is the agenda of the last Minneapolis meeting.

   Agenda bashing, Chairs (5 min)
   DT2 Update, David&Marcelo (5 min)
   DT1 Update, Tony&Iljitsch (5 min)
   MAST, Dave Crocker (15 min)
   draft-arifumi-tcp-mh-00, Arifumi Matsumoto (10 min)
   draft-ohta-multihomed-isps-00, Masataka Ohta (15 min)
   draft-ohira-assign-select-e2e-multihome-02, Kenji Ohira (10 min)
   LIN6 update, Masahiro Ishiyama  (5 min)
   draft-nordmark-multi6-threats-00, Erik Nordmark (5 min)
   draft-nordmark-multi6-noid-01 and draft-nordmark-multi6-sim-01, Erik Nordmark (10 min)
   Update from chairs and where we go next
   Open microphone

There were a lot less than 40 presentations and the number of
proposals was even less.

> Nope. Can it handle failures in the upstream? No. Etc.

First of all, the small ISPs have multiple upstream ISPs.

It is explicitly stated in my draft, which is 3 pages long:

   It is expected that NLIs have multiple prefixes each belonging to
   multiple TLAs, all of which is delegated to sites.

NLI is an acronym of "Next Level ISP".

> comments, nor support of any kind.

That's fine, as long as you are indifferent to the issue.

However, as you actively made statement against my draft, you
are guilty.

> particular category.

My document does address the criteria for being classified in TLI.

Classification as NLI is up to TLIs.

> It does not address what would happen if an ISP 
> grow, get's split/divided.

No, of course.

What if, an ISP having a global routing table entry grow, get's
split/divided?

The issue is orthogonal to my draft.

> It does not address what the financial 
> models for transit would be.

No, of course.

It is a policy issue orthogonal to my draft.

> It does not address the non-balance of 
> local vs global traffic coverage.

No, of course.

For TLI, only the global traffic is important.

> It does not take into account the 
> current peering economics of the Internet.

No, of course.

It is a policy issue orthogonal to my draft.

> So it's really hard to say 
> anything regarding it.

which means you have been indifferent to multi6 issues.

> Which is a limiting factor that I think you will that customers will 

Huh?

What can the customer do, then?

Note that it is not acceptable for the customer to switch to
other ISP only to change its address.

> ISP. It's to discourage signing up with that ISP in the first place.

What if an ISP bankrupts (like UUNET) and stop operating?

Are you saying to discourage signing up with any ISP which
may possibly stop operating in the future?

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 22 Jun 2004 15:14:08 +0200

> There were a lot less than 40 presentations and the number of

Since the first meeting in Vienna there have been a lot more 
presentations. I didn't say anything about Minneapolis. Whatever.

> First of all, the small ISPs have multiple upstream ISPs.

Yes?

> NLI is an acronym of "Next Level ISP".

Yes? And if the end host selects an address that belongs to a TLI that 
has a internal network failure and the traffic is blaockholed in that 
providers network, how does the end node find out? TCP timeout?

> That's fine, as long as you are indifferent to the issue.

I am not. But it's the multi6 WG that will have to end up selecting 
what to move forward.

> However, as you actively made statement against my draft, you

"Guilty"!? Whatever.

> Classification as NLI is up to TLIs.

So each TLI can have their own policy for their down-stream NLIs? Who 
decides who are the TLIs?

> What if, an ISP having a global routing table entry grow, get's

Actually, this is an issue today. Not a complex one, but there is 
policies in place for it. And if a TLI no longer is a TLI, that will 
have implications on down-streams.

> It is a policy issue orthogonal to my draft.

Your draft does makes assumptions on how the policy would like. It 
actually makes assumptions that are very different from the model of 
today so I think it would be reasonable to explain the thinking. 
Otherwise I don't think to many ISPs will be interested.

> For TLI, only the global traffic is important.

What about TLIs that do have large customer bases in local networks? 
What about very dominant local players that today can force large ISPs 
to peer simply because of the dominance in particular markets?

> It is a policy issue orthogonal to my draft.

Again, if you propose something that ignores the polices as they are 
implemented in todays Internet, I would expect at least some 
elaboration on how you see todays ISPs adopt this scheme.

> What if an ISP bankrupts (like UUNET) and stop operating?

It creates a nightmare for it's customers. Been there, done that, and 
have plenty of T-shirts to prove it. I think you miss the point. 
customers do not want to renumber if their _ISP change upstream_. That 
have a financial impact on them without them having control of the 
decision.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Jun 2004 22:25:19 +0900

Gert Doering;

> So the *proof* mentioned above consists of "your personal feelings what 
> the upper limit on the routing table size should be"?

No. I gave the upper bound considering the current number of unit
of global policies ((UN approved) countries and (self qualified)
tier1 providers) and concluded 1000 is large enough.

> While I honour your feelings (I also think that the routing table 
> shouldn't grow out of bounds), this is no "proof" that it's not going
> to scale.

As you agree that there should be bounds, any policy not
incorporating the bounds does not scale. QED.

> Also it brings back the problem of "who is worthy enough to receive
> one of 8192 TLAs", which was abandoned some 5 years ago, because there
> is no entity that can make this decision.

But, we have entities to define address allocation rules.

So, it is merely an issue to have an agreeable rule.

For example, assign 3 TLAs to NICs operating ccTLDs. NICs of
countries are assigned one more for each population of 10 million.
Then, have 500 for initial auction with lease period of a year with
10 more supplied monthly for 5 years. There will be about 2,000
TLAs, yet.

> Of course.  But I tend to believe if people tell me "10k routes are no
> problem today".  Oliver is building routers, with fast memory, and 
> good routing table lookup algorithms.

Be careful. I'm not offending Oliver. But, it should be noted
that, in general, router vendors, especially large ones, want
to keep their product as expensive as possible.

And, now, though I may offend Oliver, router engineers do their
work in a way they have been doing.

So, it is possible to have a router with 10k routes today
and tomorrow. But, it will costs almost as much as today
even in tomorrow.

However, it is a lot less expensive if global routing can be
performed only by looking 13 bits of the address.

There is no associative memory necessary.

It's just a memory of 8K entry with no associativity.

I think it is still reasonable to have an associative memory
of, say, 1K entry, for local routing.

> Today, high end routers can handle 140k routes.

How much does it costs?

How much do low end routers with 1G ethernet interfaces costs?

> This is not going to work.  *Inside* your AS, you will always have
> some more routes,

Sure. It does work. See above.

> and depending on the quality of your IGP aggregation,
> you might easily end up with more than 10k *internal* routes.

It's a poor operation, which costs.

> So no matter what upper bound you put on the external routes, you
> cannot assume that nobody will ever need more routing table entries.

Those requiring a lot IGP entries should pay the cost by
themselves.

> Out of interest: what number do you suggest for the hard upper bound?

8K for the global routing table, though I think, with reasons,
1K is large enough.

> Actually, no.  Not even in IPv4 today (which is part of the problem,
> that you can inject your prefix from a Cisco 2500 router, while
> everyone else needs to buy $costly hardware to *carry* your prefix).

Yes and no. IPv4 today is hopeless, because of legacy randomized
allocation of class Cs, which is why multi6 is not multi4.

The charter of multi6 says:

   but IPv6 represents an opportunity for more scalable
   approaches. IPv6 differs from IPv4 in ways that may allow for
   different approaches to multihoming that are not immediately
   applicable to IPv4.

   relatively few IPv6
   address blocks have been given out (i.e., there are no issues with
   legacy allocations as in IPv4).

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Jun 2004 22:59:52 +0900

Kurt Erik Lindqvist;

>>First of all, the small ISPs have multiple upstream ISPs.

It does scale.

It can handle failures in the upstream.

> providers network, how does the end node find out? TCP timeout?

Read the draft of end to end multihoming.

It is an issue of transport/application layer.

Application running over TCP can use default TCP timeout or
modify it.

Application may use UDP with its own timeout.

> I am not.

You have been.

> But it's the multi6 WG that will have to end up selecting 
> what to move forward.

It's your problem that you failed to properly control the WG.

> "Guilty"!? Whatever.

See the subject.

> decides who are the TLIs?

If you need an example policy, read the draft.

> have implications on down-streams.

Sure. So, even if you directly subscribe to an TLI, you may
have to renumber. Fair enough.

> Your draft does makes assumptions on how the policy would like.

My draft does not make any assumption on how the policy
would like.

You failed to give specific example for counter argument.

> to peer simply because of the dominance in particular markets?

Dominant local players may be treated as NLI or it can be an
independent TLI.

I know Yahoo, for example, has certain influence on its ISPs.

> elaboration on how you see todays ISPs adopt this scheme.

I do recognize the policies and says them orthogonal.

> have a financial impact on them without them having control of the 

You miss the point. I'm saying all the ISPs have chance to change
its prefix.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 22 Jun 2004 16:14:19 +0200

> Read the draft of end to end multihoming.

Ok, so you are actually proposing that we

a) Change the allocation policies according to  
draft-ohta-multihomed-isps-00.txt

and

b) Adopt the mechanisms in draft-ohta-e2e-multihoming-06.txt

?

> It is an issue of transport/application layer.

So we need to modify the application layer according to the e2e draft?

> Application may use UDP with its own timeout.

So all UDP applications need to modified (or not used at multihomed 
sites)?

> It's your problem that you failed to properly control the WG.

This is a discussion that doesn't belong here, but it's not the role of 
the WG chairs to control the WG. It's the chairs job to conclude what 
solutions there are support for and which ones there are not. This is 
the reason for the classification of solutions sent to the multi6 WG 
and the statement that many of them simply do not have any support.

> If you need an example policy, read the draft.

Make a bidding round for the TLI roles? So you want an open market for 
default-free address space?

> I know Yahoo, for example, has certain influence on its ISPs.

So Yahoo would qualify as a TLI? If they won a TLI assignment in the 
bidding round? While for example NTT might not?

> I do recognize the policies and says them orthogonal.

Well, the bidding for address space has a large chance to off-set the 
financial models of the Internet today.

> You miss the point. I'm saying all the ISPs have chance to change

Why would customers go to NLIs in the first place? I for one would only 
by service from TLIs.

- - kurtis -

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Jun 2004 16:23:46 +0200

Ohta-san,

Which part of your previous message provides me guidance on how your 
solution will solve scaling problems?

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Jun 2004 23:51:45 +0900

Kurt Erik Lindqvist;

> Ok, so you are actually proposing that we

I'm actually proposing that you read the draft, if you
are interested in multi6 issues.

Then, if you have any question, ask, hopefully with
proper quoting of the draft.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 00:01:54 +0900

Kurt Erik Lindqvist;

> So all UDP applications need to modified (or not used at multihomed 

If there is a family of UDP applications sharing the same
idea on "connection", there can be a set of connection
management library functions shared by the applications.
Then, it may be that only the library may be modified.

> the WG chairs to control the WG.

Then, it was your mistake that you controlled the WG to forbid
presentations of proposals.

> default-free address space?

Read the draft for an example. It does not say "open".

> bidding round? While for example NTT might not?

Read the draft.

> financial models of the Internet today.

As explained in my presentation, it does not.

> Why would customers go to NLIs in the first place? I for one would only 

It is you who are ignoring the reality.

Why do customers today buy service from tier2 providers?

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 00:06:19 +0900

Eliot Lear;

Hi,

> solution will solve scaling problems?

Scaling problems of which?

If we have hard limit on the global routing table size, there is
no scaling problem on the global routing table size.

The question is whether we can put the limit or not.

Considering that the global routing table entries are for global
policy control, we don't need so much entries much more than
those having real global policy, that is, (self qualified) tier1.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jun 2004 17:20:32 +0200

Since Kurtis took off his co-chair hat for this thread,
I will put mine on.

This is not a fruitful discussion, and it certainly
should not be cross-posted.

As Kurtis said, there have been no indications of support
for Masataka's draft in multi6, so subject to the minutes of
the recent meeting being sent to the list and agreed,
it is off the table.

Since multi6 has not firmly identified a solutions direction,
and no work on a specific solution is chartered in the IETF yet,
it's premature to discuss possible impact of multi6 on RIR policy.

Brian
   multi6 WG co-chair

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 00:32:02 +0900

Brian E Carpenter;

> for Masataka's draft in multi6,

As you give no chance to discuss it at the meeting, it is
not a valid decision.

> so subject to the minutes of

Thank you for yet another demonstration of poor chairing.

WG can't decide something at the meeting.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 22 Jun 2004 18:06:48 +0200

> are interested in multi6 issues.

For the record for the RIPE address policy WG, I will take this 
discussion over to multi6 only.

- - kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jun 2004 18:22:38 +0200

> As you give no chance to discuss it at the meeting, it is
No solutions drafts were discussed in detail at the meeting.
As you can tell from the agenda, the MP3 archive, and the
jabber log, and will see in the minutes, we analyzed the classes
of solutions.

> WG can't decide something at the meeting.

No, this is an example of correct chairing. The consensus formed
in the meeting will be recorded in the draft minutes, and the draft
minutes will be sent to this list for validation of the consensus
on the list.

It takes longer to prepare the minutes of a full day's meeting
than those of a normal IETF session, especially when distracted by
impolite emails.

I have deleted your inappropriate cross-postings.

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 03:39:36 +0900

Kurt Erik Lindqvist;

> Several times today alone, otherwise I wouldn't remember what it said.

OK.

> If we concentrate on the  draft-ohta-multihomed-isps-00.txt proposal 
> alone :

That's fine. The architectural draft is not essential for today's
topic.

> If I pick a Tier-2 or Tier-3 provider, I will in most 
> cases get addresses provided out of their PA allocation. 

Seemingly, you think that NLIs peering with a TLI must be
delegated TLI's prefix.

However, ISPs are still free to peer with any other ISPs
without sharing a prefix. Though it increases number of
prefixes within ISPs it is a local policy issue of ISPs
on how much extra prifixes they carry.

The requirement, instead, is that NLIs delegated a TLI's
prefix must peer with the TLI, not vice versa.

>>This doesn't fly. He can't set his own routing policy and he can't 

is wrong and the remaining issue is renumbering.

>> If he changes the single upstream his customers needs to 

That is true on any upstream prefix change, though adding a TLI
as a peer does not necessarily mean adding a prefix.

Then, you miss one thing.

There supposed to be a hard limit on the number of TLAs.

Considering that there will be new TLIs, old TLIs must
retire.

Thus, no TLI is assured to remain to be TLI forever.
I
> I, as a customer, would then much rather be a customer of 
> the TLI directly, that would assure me that I would have stable 
> addresses,

There is no such stability assured.

> That 
> allocation is permanent with the ISP as long as they exist and pays 
> their RIR (and in most cases long after they don't pay their RIR).

That is the assumption which is no longer valid with the introduction
of the hard limit on the number of global routing table size.

ISP hierarchy is inessential.

So is the theory.

Now, consider the reality.

If the hard limit is large enough (I think 8192 is so), TLI changes
will be infrequent.

TLA allocation policy should have mechanism to allow an ISP recover
from accidental loss of TLI status. For example, an ISP may be allowed
to use its TLA one year after its lease period has expired and to
continue to use it (with penalty fee or something like that) if the
ISP recover its TLI status witin a year.

NLIs seldom change their set of prefixes for obviouis commercial
reasons. Even if they do, there will be long notification and
transition periods. End users are free not to add new prefix,
though they sacrifice some robustness. When a prefix from a TLI
is deleted, NLIs with good economical condition will immediately
stop advertising old prefix to end users but keep peering with the
TLI and keep routing packets with old prefix for the time being.
Thus, end users can keep using the old prefix.

On the other hand, ISPs (including TLIs) without good economical
conditios will keep bankrupting and stopping operations without
much prior notices, which has nothing to do with the addressing
architecture.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Jun 2004 20:48:39 +0200

> of, say, 1K entry, for local routing.

Most routers don't use associative memory or CAMs for routing table 
lookups, this is mostly done for layer 2 switching.

In addition to using a CAM, obviously any kind of data structure can be 
used to store routing information, such as linked lists (not efficient 
as they must be searched serially), arrays or various types of trees. 
Vendors such as Cisco and Juniper use n-way tries for this, which is 
generally quite efficient even for lookups in very large tables.

(Note though that looking up routes for the purpose of forwarding is 
not the main operational issue with a large routing table, as this 
scales at worst at O(log(n)): the real problem is processing updates, 
which scales at O(log(n)*n), and convergence times after links come up 
or go down, which scale linearly.)

I don't think CAMs are the right solution, as they are very inflexible 
and also very power-hungry. If a more efficient lookup mechanism is 
desired, it would probably make sense to see if it's possible to store 
the routing table in a flat array. This way, looking up a route always 
takes one memory cycle, it doesn't get much better than that. Obviously 
then the routing table must fit in memory, which means the longest 
prefixes that can be looked up this way are in the order of 26 bits. 
This is pretty close to the length of prefixes given out by the RIRs.

In any event, I think putting an artificial limit on the size of the 
routing table is probably more harmful than useful, especially in the 
long run and/or if the limit is quite low such as 8k.

A more fruitful approach would be to look at mechanisms to remove 
unnecessary routing information from routing tables. The obvious way to 
do this would be to take advantage of geographic grouping of prefixes 
where possible.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 04:29:37 +0900

Gert Doering;

Hi,

> Something that right now confuses *me* is:  If I understand this
> correctly, the 'default-free zone' is meant to be kept below 1000
> routes, so routers can be fast.

The hard limit is, IMO, 8192.

> But what about the internal 
> structure of all these networks?  At least the "internal core" boxes
> need to know all routes for the "NLI"s (or the NLIs' customers), which 
> might well be many 1000s...

You are right.

There is nothing mentioned in the draft, but I suggested 1000
today, which I still think enough for TLI internal, but should
not be enough for NLI. Do you have any suggestion?

Note that routers in NLIs may have less performance than those
in TLIs.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 04:44:33 +0900

Iljitsch;

> lookups, this is mostly done for layer 2 switching.

It is because CAM is not large enough for the global routing table.

Let's assume that the number of local route is smaller
than CAM size.

> generally quite efficient even for lookups in very large tables.

1K CAM is very fast.

> (Note though that looking up routes for the purpose of forwarding is not 
> the main operational issue with a large routing table, as this scales at 
> worst at O(log(n)):

Note that the amount of hardware is O(n).

Note that it costs more than O(log(n)) times to make already fast
memory O(log(n)) times faster.

Note that, with planar layout, there is O(sqrt(n)) factor.

> the real problem is processing updates, which scales 
> at O(log(n)*n), and convergence times after links come up or go down, 
> which scale linearly.)

Yup.

> I don't think CAMs are the right solution, as they are very inflexible 

Consider a router on a chip, which is very inflexible, anyway.

A router in a chip is a lot more faster than a router on two chips.

> the routing table in a flat array.

TLA addresses are supposed to be accessed so.

> This way, looking up a route always 

Large memory is slow. Note also your comment on BGP convergence.

> long run and/or if the limit is quite low such as 8k.

Why do you think 8k quite low?

> do this would be to take advantage of geographic grouping of prefixes 

Then, how may route, do you think, is enough?

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jun 2004 23:54:57 +0200

> There supposed to be a hard limit on the number of TLAs.

The concept of TLAs was removed from the IPv6 architecture
quite some time ago.

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 07:00:15 +0900

Gert Doering;

> Why?

Because with minimum peering global traffic concentrates on peerings
between TLIs and because minimum links make the traffice concentrate
on backbone links of TLIs.

With extra links, extra peerings and associated policies, it is
possible to reduce the concentration or even have an NLI link
carry more traffic than links of TLIs.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jun 2004 23:57:44 +0200

I don't think this topic is relevant to the next steps planned
for this WG, and it is a very old story that has been discussed
often for more than ten years.

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 07:12:51 +0900

> The concept of TLAs was removed from the IPv6 architecture

It is it a problem, as discussed in the past meeting.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 07:25:59 +0900

> often for more than ten years.

Thank you again for yet another demonstration of poor chairing.

The current most "Description of Working Group" in WG homepage,
content on which chairs are highly responsible, still says;

	IPv6 differs from IPv4 in ways that may allow for
	different approaches to multihoming that are not
	immediately applicable to IPv4. For example, IPv6 has
	larger addresses, hosts support multiple addresses per
	interface, and relatively few IPv6 address blocks have
	been given out

						Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Jun 2004 00:01:03 +0200

Masataka,

> It is because CAM is not large enough for the global routing table.

Hm, is there a reason why CAMs can't be made big enough for this?

> 1K CAM is very fast.

Of course. The trouble with CAMs is that they use a lot of power and 
run very hot. Regular memory searches are more efficient and usually 
also fast enough.

>> not

> Note that the amount of hardware is O(n).

Just the memory; most of the other stuff is O(r) where r = number of 
routers or number of linecards.

> memory O(log(n)) times faster.

Certainly. But as long as the increase in bandwidth is equal or lower 
than the log of the increase in memory speed, we're ok. Relative to the 
memory speed requirements to read and write packets at a certain 
bandwidth, the memory speed requirements for looking in the routing 
table is probably not a big issue. (Although the former may be done 
using small amounts of expensive memory while storing a very big 
routing table in such expensive memory isn't much fun for the people 
who have to pay the bill.)

> Note that, with planar layout, there is O(sqrt(n)) factor.

What do you mean?

> A router in a chip is a lot more faster than a router on two chips.

Hm, but what problem are we solving here? There are two reasons for 
having very fast routers: either because you aggregate a lot of 
traffic, or because you have a lot of traffic going in / coming out of 
a single place. In the former case speed is only useful if it's 
affordable: if a 40 Gbps router is 3 times more expensive than 4 10 
Gbps routers, ISPs will redesign their networks to use a larger number 
of smaller routers. In the other case, it may very well be possible to 
build routers that take advantage of the application scenario. I.e., 
many packets are going to go in the same direction, so a 
flow/destination cache based forwarding path would be appropriate here. 
(Note that this is deadly in an ISP environment where there are many 
thousands of new flows per second.)

> Large memory is slow. Note also your comment on BGP convergence.

Slow memory is still pretty fast! At 10 Gbps you can do 14.8 million 
packets per second. With today's RAM it's possible to transfer over 500 
MB per second so that compares quite favorably, although this speed is 
for serial access rather than random access of course.

> Why do you think 8k quite low?

There are already 135k IPv4 routes out there, but more importantly, 30k 
AS numbers assigned and 15k in use. So at 8k routes half the ASes that 
are globally visible in v4 today would have "disappear".

> Then, how may route, do you think, is enough?

Hard to say. But I really wouldn't want to decide on a fixed number. 
Rather, I would like the IPv6 internet to "work" with a low number of 
highly aggregated routes, at least in the core were speed is 
everything. However, in places where routers can accommodate larger 
routing tables, it would be beneficial to do controlled deaggregation 
to take advantage of better optimized paths.

I once did some experimenting and if I remember correctly, 75% of 
traffic used only 10% of all routes. So it might make sense to build a 
fast core with only 10% of the global routing table in it which can 
then take care of this 75% of traffic. The remaining traffic can then 
be tunneled or routed over an auxilary network. On the other hand, if 
routers can take a full routing table it wouldn't be smart to go 
through all this hassle. So we need to be flexible.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 22 Jun 2004 18:15:54 +0200

Ohta-san,

What you are describing is different service I as a customer would get 
from my Tier-2/NLI provider. With the model described in  
draft-ohta-multihomed-isps-00.txt I as a customer would have to change 
IP addresses if the NLI/Tier-2 provider decided to use another TLI for 
_their_ commercial reasons. This change will have an economic impact on 
me as a customer that I would need to recover from my provider, or be 
prepared to take, without having any influence over how or when this 
would happen. I, as a customer, would then much rather be a customer of 
the TLI directly, that would assure me that I would have stable 
addresses, until _I_ decide to change provider and take the cost of 
renumbering. This is significantly different from how the Internet 
works today. If I pick a Tier-2 or Tier-3 provider, I will in most 
cases get addresses provided out of their PA allocation. That 
allocation is permanent with the ISP as long as they exist and pays 
their RIR (and in most cases long after they don't pay their RIR). If I 
decide to change providers, I change addresses. Again, then it's my 
decision as a customer that will trigger this.

We have very different views on how the Internet operates today and 
what the underlaying model is. Let's leave it at that.

- - kurtis -

---

From: Jeff Williams <[email-masked]>
Date: Wed, 23 Jun 2004 04:35:27 -0700

Masataka-sama and all,

  Open to some does not mean "all the way open" to others.  So restrictions
for the sake of how far "Open" discussion is, is dependent sometimes on
whom is discussing what aspect of relevant issues on a topic area...

  That said, I liked your draft.  I still must study it more however.

> Why do customers today buy service from tier2 providers?

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jun 2004 15:56:27 +0200

It's interesting that the person who writes under the pseudonym
"Jeff Williams" has start sending his or her usual nonsense to
the multi6 list. I advise everybody to not waste their time
reading messages from "Jeff Williams", and above *do not*
respond, because we know from experience that even more
nonsense comes back as a result.

     Brian

Jeff Williams wrote:

<blah blah blah>

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Jun 2004 08:52:57 -0700

Brian,

If someone is posting under a pseudonym, please indicate who you believe 
the real author is and why.

As to whether to reply, I would prefer that you let the WG decide that 
for themselves. Blackballing posters is an extreme measure, and 
shouldn't be done unless absolutely necessary. Besides, trolls are 
everywhere.

Joe

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 23 Jun 2004 18:05:57 +0200

Hi Joe,

I was "spammed" by "Jeff Williams" in another mailing list during some time, with very strange comments and opinions and only because Brian show me the complete history, I realized I was being cheated.

Actually I received a couple of days ago a private email from Jeff (again in response to an email in another mailing list in RIPE), and I just ignored it ;-)

Is like another more "Jim Fleming" I guess ... or may be is him with another email account !

Regards,
Jordi

----- Original Message ----- 
From: "Joe Touch" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 23, 2004 5:52 PM
Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")]

Brian,

Joe

> nonsense comes back as a result.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jun 2004 21:23:51 +0200

Joe,

Nobody has ever traced the person behind "Jeff Williams". I'm
surprised you haven't come across his or her output before.
I make no apology for attempting to prevent him or her
wasting our time, as he or she has wasted time of many other
IETF WGs in the past.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Jun 2004 13:16:41 -0700

I've come across the posts of many trolls, many of whom waste time. Is 
there some reason you believe Jeff Williams is more of a pseudonym than 
any of the other trolls?

I.e., if you're going to make that accusation (of pseudonym), please 
include the reasons for the accusation.

Joe

Brian E Carpenter wrote:
>> If someone is posting under a pseudonym, please indicate who you 
>> believe the real author is and why.
>>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jun 2004 06:15:41 +0900

Havard Eidnes wrote:

Thank you for good examples.

> Past history has told us that at least some technologists have
> failed miserably in predicting whether fast routers can be built
> which handle largish routing tables.

And, I happened to be a technologist who know how to build a
fast (Pbps or more) router even before no one have the needs.

So, the only problem on fast routers is their prices.

Limiting the number of global routing table entries helps a lot.

With no loops in the forwarding path of routers, the limiting
factor is latency of routing table look up. While parallelism
is a solution, it does not reduce the routing table size. So,
to reduce the prices of routers, it is better to reduce the
routing table size.

Their are poeple who use science to prove that it is impossible
to make flying machines.

Their are people who use science to make flying machines more
efficient and less expensive.

> If I recall correctly, an argument similar to the above one was
> one of the arguments the ATM proponents used in their day: you
> need a short header to do fast lookups, and "fast IP routers
> cannot be built".  History since then has at least told me that
> this was not entirely accurate.

At that days, my theory explained why ATM is about 10 times
slower than IP.

The theory is simply that, given 28 bit address with hierarchy
(VPI/VCI or more), it is almost as complex as processing 32
bit IP. So, it takes about 10 times more amount of work to
process 48B chunks than 500B-in-average chunks. Of course, there
are other factors obscuring the essential difference.

> Therefore, I tend to view the above justification and limits with
> a healthy dose of scepticism.

So, you can still insist that my theory is incorrect and ATM is
8192 or more times faster than IP, while I can keep saying ATM
is about 10 times slower than IP with reasons.

I can also say 8192 is large enough for the number of global
routing table entries with reasons.

You can alsy say IPv6 is no good because 128 bit address is not
long enough.

But, it's your limitation, not mine.

							Masataka Ohta

PS

Note that there are people who analize that large routing table
increases the time for BGP convergence.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jun 2004 23:44:59 +0200

Joe,

Try http://www.gtld-mou.org/gtld-discuss/mail-archive/08030.html

It's 5 years old; Google might find something more recent if
you can be bothered. I can't.

    Brian

Joe Touch wrote:
>>> As to whether to reply, I would prefer that you let the WG decide 
>>> that for themselves. Blackballing posters is an extreme measure, and

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Jun 2004 14:49:32 -0700

Thanks. That was what I wanted included in the multi6 archives.

Joe

Brian E Carpenter wrote:
>> there some reason you believe Jeff Williams is more of a pseudonym 
>> than any of the other trolls?
>>

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 24 Jun 2004 00:41:57 +0200

Someone forwarded me a couple more:

http://www.dnso.org/clubpublic/ga/Arc09/msg01569.html
http://www.gtld-mou.org/gtld-discuss/mail-archive/08015.html

I also found:
http://www.fitug.de/icann-europe/0106/msg00018.html
http://www.dnso.org/clubpublic/ga-full/Arc00/msg00089.html
http://www.dnso.org/clubpublic/ga-full/Arc00/msg00094.html
http://www.gtld-mou.org/gtld-discuss/mail-archive/07997.html

Regards,
Jordi

---

From: Jeff Williams <[email-masked]>
Date: Wed, 23 Jun 2004 18:31:10 -0700

Brian and all,

  Oh sure! You know better Brian...

---

From: Jeff Williams <[email-masked]>
Date: Wed, 23 Jun 2004 18:42:44 -0700

Joe and all,

  I'll be brief on this silliness one more time.

  Brian and I have had some "run-ins" from time to time.  I
won't necessarily agree with him in areas where I feel, know,
or otherwise believe are either incorrect or could be better.
Brian has taken offense to how I state my or our organizations
ideas or positions.  I am sorry he does.  We and I have our
styles, which it has from time to time seemingly offended Brian,
Randy and a few others within the IETF.  My own personal
opinion is that most of this silliness is borne of ego, rather than
sound reasoning, though sound reasoning is, and has been
present during several differences of opinion between Brian
or Randy and I...

Joe Touch wrote:

>   ------------------------------------------------------------------------
>
>                           Name: signature.asc
>    signature.asc          Type: application/pgp-signature
>                    Description: OpenPGP digital signature

Regards,

---

From: Jeff Williams <[email-masked]>
Date: Wed, 23 Jun 2004 18:58:32 -0700

Joe and all,

  I am not a pseudonym.
See for instance:
http://www.ntia.doc.gov/ntiahome/domainname/proposals/ineginc/ineginc.htm

  So this is just one of Brian's terribly unfortunate methods of attempting
to justify his ego, IMHO...

Regards,

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jun 2004 23:06:27 +0900

> whom is discussing what aspect of relevant issues on a topic area...

So true.

>   That said, I liked your draft.  I still must study it more however.

Thank you.

However, such statement without technical reasoning is no better
than the emotional postings by Brian Carpenter.

So, let's have discussions on technical points with verifiable
reasons.

Note, for example, that I oppose any proposal trying to import
*THE* swamp of v4.

							Masataka Ohta

---

From: Jeff Williams <[email-masked]>
Date: Thu, 24 Jun 2004 21:16:13 -0700

Masataka-sama and all,

> >   That said, I liked your draft.  I still must study it more however.

  Your welcome, but also  you earned it.

> than the emotional postings by Brian Carpenter.

  Understood to a degree.  My comment was also meant to be
in reference to already discussed by others, your draft, including
the already stated technical reasoning and disagreement...

> Note, for example, that I oppose any proposal trying to import

  I also.  v6 is a very different technically, animal than v4.  I am however
not a fan of v6 vs v8.  But that is another discussion all together.

Regards,

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Jun 2004 13:49:12 +0200

Hi,

So that would be a maximum of 10.000 routing table entries (if we
can manage to keep it at "1 prefix per LIR").

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  60210  (58081)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Jun 2004 14:35:09 +0200

Hi,

[..]

This is not going to work.  *Inside* your AS, you will always have
some more routes, and depending on the quality of your IGP aggregation,
you might easily end up with more than 10k *internal* routes.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Jun 2004 20:58:36 +0200

Hi,

> discussion over to multi6 only.

I would appreciate if you could send us an "executive summary", so
that people over here that are not so well-versed in the different
multi6 proposals can try to judge the benefits and costs of this
proposal.

routes, so routers can be fast.  But what about the internal

thanks,

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Jun 2004 22:34:12 +0200

Hi,

Why?

Gert Doering
        -- NetMaster

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 23 Jun 2004 16:22:29 +0200 (CEST)

Regards,

- Håvard