Subject: Routing table size?

From: masataka ohta <[email-masked]>
Date: Sun, 12 Oct 2003 19:17:47 +0900

Dear all;

How, do you think, will the size of global routing table be?

As I raised the question before Vienna, Brian said it should
be proportional to logarithm of the network size.

Is it agreeable?

If so, the next question is on the base of the logarithm.

						Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 12 Oct 2003 13:00:08 +0200

> How, do you think, will the size of global routing table be?

When?

> be proportional to logarithm of the network size.

Not if the RIRs don't change their policies. They give out /32s so 
there is a linear relationship between the number of /64s / /48s in use 
and the number of distinct entries in the global IPv6 routing table.

I vote we fire the RIRs as soon as v4 is obsolete because they just 
don't get it. (And they're costing the community way too much money to 
boot.)

Assuming we'll see significant v6 deployment, my guess is 15k - 60k by 
2010 (depending on the success of our efforts here), at which point the 
v4 table will be around 200k.

---

From: "Ray Plzak" <[email-masked]>
Date: Sun, 12 Oct 2003 07:14:57 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Sunday, October 12, 2003 7:00 AM
> To: masataka ohta
> Cc: [email-masked]
> Subject: Re: Routing table size?
> 
> 
> Not if the RIRs don't change their policies.

Policies in the RIR service regions are made by the operators and users
of the Internet as well as anyone else that is interested in IP
addressing, routing, and related issues, not by RIR staffs or their
Boards.  If you feel that a particular allocation policy is not correct,
then I suggest that you participate in the RIR forum in the area where
you are located.  Mail lists are open, there is no qualification to
join.

> don't get it. (And they're costing the community way too much 

You should start by firing yourself, because if you are not actively
involved in the policy process then you have only yourself to blame for
the policies as they exist.  Become involved.

Ray

---

From: masataka ohta <[email-masked]>
Date: Sun, 12 Oct 2003 21:08:42 +0900

Iljitsch;

>> How, do you think, will the size of global routing table be?

For the lifetime of IPv6 or, at least, multi6.

> v4 table will be around 200k.

Such an unfounded statements is not an input for constructive discussion.

							Masataka Ohta

---

From: masataka ohta <[email-masked]>
Date: Sun, 12 Oct 2003 21:14:51 +0900

Ray;

> you are located.  Mail lists are open, there is no qualification to

Should we join mailing lists of all the RIRs and expect their
policies become magically consistent?

Or can we expect some central place (if ICANN is hopeless, RIPE is
fine for me) for the discussion?

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 12 Oct 2003 14:40:17 +0200

> For the lifetime of IPv6 or, at least, multi6.

So how long is that going to be?

>> assuming we'll see significant v6 deployment, my guess is 15k - 60k 
>> by 2010 (depending on the success of our efforts here), at which 
>> point the v4 table will be around 200k.

> Such an unfounded statements is not an input for constructive 

We're all familiar with the underlying data, so why repeat it here?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 12 Oct 2003 14:46:43 +0200

On zondag, okt 12, 2003, at 13:14 Europe/Amsterdam, Ray Plzak wrote:

>> don't get it. (And they're costing the community way too much
>> money to boot.)

> the policies as they exist.  Become involved.

Hm, yes, firing myself would work out well as being involved in the 
entire I* family is a full time job in itself.

Or maybe people can learn to take constructive criticism (which I agree 
not all of what I said was) to heart rather than play procedural games.

Giving out /32s ONLY in IPv6 and /20s mostly in IPv4 isn't a good 
policy. Sometimes people need to be globally visible without the need 
for such a large block, and the largest ISPs burn through them fast 
enough to warrant giving them much larger blocks.

---

From: masataka ohta <[email-masked]>
Date: Sun, 12 Oct 2003 21:51:32 +0900

Iljitsch;

> So how long is that going to be?

It will be long before, if ever, there are 2^128 hosts or 2^64 subnets.

> We're all familiar with the underlying data, so why repeat it here?

The only meaningful underlying data is that the global routing table
size of IPv6 is *SMALL*.

							Masataka Ohta

---

From: masataka ohta <[email-masked]>
Date: Sun, 12 Oct 2003 22:00:15 +0900

Iljitsch;

> enough to warrant giving them much larger blocks.

Large? How large?

The only real requirement is global visibility and, with IPv4 today,
it is granted to an ISP with multiple external connectivities, which
is not necessarily the case with multi6. 

						Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 12 Oct 2003 15:26:51 +0200

> Large? How large?

Double the size of each next block? Probably want to stop doing that at 
some point, though...

> is not necessarily the case with multi6.

Actually it doesn't work like that in IPv4 either. You can get an AS 
number if you multihome, but for your own address block you need to 
show immediate use for a /22 (in the RIPE region).

As for the IPv6 routing table: yes, of course it is small. IPv6 
deployment is small. The Empire State Building was small too the first 
week of construction.

It seems reasonable that everyone with an AS number will want to have 
an IPv6 address block at some point. That's nearly 30k at this moment.

---

From: masataka ohta <[email-masked]>
Date: Sun, 12 Oct 2003 22:51:28 +0900

Iljitsch;

> Double the size of each next block? Probably want to stop doing that at 

Huh? Next block? Double?

> Actually it doesn't work like that in IPv4 either.

Though I can't understand you, you should fight in some RIR on
IPv4 issues, first.
 
> It seems reasonable that everyone with an AS number will want to have an 
> IPv6 address block at some point. That's nearly 30k at this moment.

That's fine.

							Masataka Ohta

---

From: "Ray Plzak" <[email-masked]>
Date: Sun, 12 Oct 2003 09:54:21 -0400

There is a global ipv6 policy dicussion list hosted by APNIC.

http://www.apnic.net/community/lists/index.html

Ray

> From: masataka ohta [mailto:[email-masked]] 
> Sent: Sunday, October 12, 2003 8:15 AM
> To: Ray Plzak
> Cc: [email-masked]

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 12 Oct 2003 15:54:25 +0200

-----BEGIN PGP SIGNED MESSAGE-----

masataka ohta wrote:

<SNIP>
> The only meaningful underlying data is that the global routing table

Currently 400 real TLA's and some ISP's have a max of 500 prefixes.
So that is indeed small. There is to wonder though why some ISP's
don't aggregate their own routes, especially when they have the
same ASPaths. I do get why people announce more specifics though
because of 'multihoming'. I have my own thought about that though.

Btw as can be read on the following URL Marc Binderberger made
a "policy based routing' patch for FreeBSD 4.8:
http://www.sixxs.net/forum/?msg=setup-52946
Allowing multiple upstream prefixes but correct routing of packets.

Greets,
 Jeroen

---

From: "Ray Plzak" <[email-masked]>
Date: Sun, 12 Oct 2003 09:56:37 -0400

> Sent: Sunday, October 12, 2003 8:47 AM
> To: Ray Plzak
> Cc: [email-masked]
> Subject: Re: RIR bashing, was: Routing table size?
> 

I suggest that you subscribe to the global IPv6 policy list 

and post this thought there.

Ray

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 12 Oct 2003 16:10:20 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> enough to warrant giving them much larger blocks.

http://www.sixxs.net/tools/grh/tla/all/ shows amongst others:

2001:d70::/30   NTTWEST-IPv6-JPNIC-JP-20030912
2001:1600::/31  NL-LIBERTEL-20030902

So getting them is certainly possible.

If you want to be 'visible' with a smaller block you are an
enduser and at the moment you are out of luck. But then again
I don't know any enduser type people having the connectivity
nor the need for their own routing. That's why I pay my upstreams
so they can handle all that stuff for me and I can sleep fine :)

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 12 Oct 2003 16:28:46 +0200

> -----BEGIN PGP SIGNED MESSAGE-----

Signature still doesn't work...

> So getting them is certainly possible.

Ok, that's good. In IPv4 people received /16s in the past but these 
days I see huge numbers of consecutive /20s in the global routing 
table. In this case the RIRs did at least _something_ right but 
unfortunately it got lost in the translation somewhere. This may be 
because the RIRs give out consecutive /20s one at a time rather than a 
/16 at once, but the network in question doesn't want to install new 
aggregates remove existing more specifics because (as everyone who has 
been in IPv6 operations the past years knows) this leads to a fairly 
long period (minutes) of instability.

> enduser

Or a root nameserver...

> and at the moment you are out of luck. But then again

Ok then we can terminate this working group.

Actually you do know such an enduser: me. I have two lines coming into 
my home and I run IPv6 over both of them. In fact the server that is 
colocated with one ISP is reachable (over IPv6) through the other ISP, 
my home network and the link to the colo ISP. (Do some traces for 
www.bgpexpert.com.)

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 12 Oct 2003 17:02:18 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> Signature still doesn't work...

[OT] They fixed it in gpg, so apparently it wasn't my prob afterall :)
But gpg also has problems with multiple subkeys which have been
fixed in the latest tree too...

> > If you want to be 'visible' with a smaller block you are an

Which get /32's too but for an obvious reason.
But that is critical infra and I don't think (m)any
people will argue against rootservers being crititical.
TLD servers though can do with upstream IP's

> Actually you do know such an enduser: me. I have two lines 
> coming into  my home and I run IPv6 over both of them.
> In fact the server that is colocated with one ISP is reachable
> (over IPv6) through the other ISP, my home network and the
> link to the colo ISP. (Do some traces for www.bgpexpert.com.)

traceroute6 2001:888:1DDE:2:0:0:0:1

 7  ipv6tb.xs4all.nl (2001:888:0:3::4242)  11.033 ms  10.373 ms  10.962 ms
 8  tunnel3550.ipv6.xs4all.nl (2001:888:10:dde::2)  35.457 ms  43.098 ms  35.897 ms
 9  3ffe:2500:310:1:200:cff:fe3e:6052 (3ffe:2500:310:1:200:cff:fe3e:6052)  36.448 ms  35.899 ms *
10  sequoia.muada.com (2001:888:1dde:2::1)  57.616 ms  50.246 ms  56.188 ms

I wonder where hop 9's packets came from and how the flow to me.

 3  ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1)  5.099 ms  4.124 ms  4.654 ms
 4  e0.6b2.ams7.alter.net (2001:7f8:1::a501:2702:1)  6.661 ms *  4.357 ms
 5  sequoia.muada.com (2001:888:1dde:2::1)  50.087 ms  48.297 ms  39.151 ms
 6  3ffe:2500:310:1:200:cff:fe3e:6052 (3ffe:2500:310:1:200:cff:fe3e:6052)  39.342 ms *  42.977 ms

But indeed this is a case of multiple independent links
even though they are going over the same physical IPv4 path
and are being tunneled.

I personally see the situation where I would get two
independent ISP's, eg a cable and ADSL provider. They don't
have to know anything about eachother. The only thing they do
is that they each route a prefix from and to me as delegated out
of their TLA. My boxes thus would get 2 prefixes. For routing
packets they will pick either prefix and send out packets.
Now if one link goes down TCP connections terminate. If there
would be a server type application on the box it would then
not be reachable. Conclusion we need a way of notifying with
some trust/authentication that the IP of a certain host changed.
IMHO the best solution would be a id/loc seperation thus only
using the ISP's prefixes in transit, the hosts would use the
ID prefixes and never know anything about the routing prefixes.

But that probably all has been told and documented a lot of
times already... if someone has space for an intern to dive
into this I volunteer myself to take that place and implement
such a scheme...

Greets,
 Jeroen

---

From: masataka ohta <[email-masked]>
Date: Mon, 13 Oct 2003 00:21:56 +0900

Ray;

> http://www.apnic.net/community/lists/index.html

Thanks for the pointer.

But, having read recent posts to the ML, I have got an impression
that the mailing list is for discussion on the current IPv6
specification as is, thus ignoring the problem of routing table
size.

Or, is the mailing list an appropriate place to discuss how to
modify IPv6 or, at least, ask opinions on possible modifications
on IPv6?

							Masataka Ohta
>>>Policies in the RIR service regions are made by the 
>>
>>operators and users
>>
>>>Boards.  If you feel that a particular allocation policy is 
>>
>>not correct,
>>
>>>then I suggest that you participate in the RIR forum in the 
>>
>>area where
>>

---

From: "Ray Plzak" <[email-masked]>
Date: Sun, 12 Oct 2003 11:26:46 -0400

Ohta-san,

This list is the appropriate place to ask questions about current policy
as well as suggest changes to existing policy or even propose new
policy.

Ray

> Sent: Sunday, October 12, 2003 11:22 AM
> To: Ray Plzak
> Cc: [email-masked]

---

From: masataka ohta <[email-masked]>
Date: Mon, 13 Oct 2003 00:35:08 +0900

Jeroen;

> of their TLA. My boxes thus would get 2 prefixes.

And, you want to have 2 exit routers, if you want to avoid a single
point of failure.

Then, you want to have full route in your site to choose the best
exit router for each destination.

Or, you may develop a complex protocol on hosts and exit routers
that a host first query exit routers (multiple ones, of course)
to choose a source address and routers between the host and
the exit routers perform source address based routing (or,
the host may use tunneling to the exit routers), even in which
case, the exit routers must have a global routing table.

This is why the global routing table should be reasonably small.

						Masataka Ohta

---

From: masataka ohta <[email-masked]>
Date: Mon, 13 Oct 2003 00:40:29 +0900

Ray;

> as well as suggest changes to existing policy or even propose new

Propose new policy based on which specification?

Can the specification not necessarily the current IPv6 as is?

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 12 Oct 2003 23:04:00 +0200

> Which get /32's too but for an obvious reason.

Not so obvious... They need one address. What are the other 
79228162514264337593543950335 for?

It's a shame really that people as a rule still don't get it. In the 
old days, the  root servers had an address, and we used the named.root 
file (wasn't it called something else back then or am I confused with 
named.boot?) to find them. But we're doing so many routing tricks with 
these addresses now that it makes much more sense to group all the 
address blocks for all the roots together in a special range. Bonus: we 
get to hardcode the root addresses now too, as we're now no longer 
modifying the root addresses when something changes, but keep the 
addresses and change the routing.

>> (Do some traces for www.bgpexpert.com.)

>  9  3ffe:2500:310:1:200:cff:fe3e:6052 
> (3ffe:2500:310:1:200:cff:fe3e:6052)  36.448 ms  35.899 ms *

> I wonder where hop 9's packets came from and how the flow to me.

gw#trace
Protocol [ip]: ipv6
Target IPv6 address: 3ffe:8114:2000:240:290:27ff:fe24:c19f

   1 2001:888:1DDE:1:204:27FF:FEFE:249F 4 msec 4 msec 4 msec
   2 2001:888:0:3::4242 36 msec 36 msec 48 msec
[...]

And:

gw#trace
Protocol [ip]:
Target IP address: www.unfix.org

   1 loopback.rhadamanthus.pine.nl (213.156.3.144) 12 msec 12 msec 8 msec
   2 fa0-0.rtr0002.asmr.pine.nl (213.156.0.29) 12 msec 12 msec 12 msec
   3 fa3-0-4-asd8ro2.enertel.nl (195.7.144.85) 16 msec 16 msec 16 msec
   4 fa0-0-0-asd8ro1.enertel.nl (195.7.144.149) 12 msec 12 msec 20 msec
   5 po11-1-0-asd7ro1.enertel.nl (195.7.144.2) 16 msec 12 msec 16 msec
   6 ams-ix.intouch.net (195.69.144.93) 16 msec 12 msec 20 msec
   7 217.8.101.250 16 msec 12 msec 16 msec

But this is a bit confusing as this router connects to ISP#1, which is 
also where its IPv4 default points to but its IPv6 default points to 
the router that connects to ISP#2, which has both its v4 and v6 
defaults point to ISP#2 (I also have box that has a full v6 table but 
never mind (and I gave this router a 6bone address that belongs to the 
tunnel over ISP#1 to see if RIPng works if two routers don't share a 
subnet)):

hpromatem#trace
Protocol [ip]:
Target IP address: www.unfix.org

   1 195.190.241.114 188 msec 96 msec 116 msec
   2 32.ge-0-0-0.xr2.pbw.xs4all.net (194.109.5.201) 20 msec 160 msec 28 
msec
   3 0.ge-1-3-0.xr1.tc2.xs4all.net (194.109.5.6) 36 msec 12 msec 120 msec
   4 telecity.ams-ix.intouch.net (195.69.144.175) 300 msec 276 msec 236 
msec
   5 217.8.101.250 244 msec 116 msec 156 msec

> even though they are going over the same physical IPv4 path

Nope. One is over a "dark copper" pair with "vooroorlogse" 144 kbps 
baseband modems, the other over ADSL.

> and are being tunneled.

Yup, in both cases the router terminating the line at the other side 
doesn't grok v6.

> of their TLA. My boxes thus would get 2 prefixes.

That's my current setup for my box in the colo room at ISP#1. It has a 
tunnel over the regular ISP#1 v4 connectivity (which is of course 
multihomed in its own right) and one to my house and then to ISP#2 over 
ADSL.

> For routing
> not be reachable.

Actually for incoming traffic this wouldn't be a huge problem as 
clients retry until they hit a working address (this actually works 
fairly well today). The trouble is the source address selection, and in 
the case of tunnels, seeing which one works and which one doesn't. And 
even when all of this works it still breaks existing connections.

> Conclusion we need a way of notifying with

Actually that's not the hard part. Finding out the new address 
(assuming the internet protocol remains the same...) in such a way that 
an attacker can't get in the middle is harder.

> ID prefixes and never know anything about the routing prefixes.

Hm, yes, not so simple...

---

From: "Dmitri Krioukov" <[email-masked]>
Date: Mon, 13 Oct 2003 00:05:47 -0400

Masataka,

One of the latest model for the routing table size (growth)
explicitly including allocation policies was presented
at the last SIGCOMM,
http://www.acm.org/sigcomm/sigcomm2003/papers.html#p125-narayan
--
dima.
http://www.krioukov.net/~dima/

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of masataka ohta
> Sent: Sunday, October 12, 2003 6:18 AM
> To: [email-masked]
> Subject: Routing table size?
> 
> 
> Dear all;
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Oct 2003 08:42:59 +0300 (EEST)

Let's change the subject as there seems to need some discussion..

> This is why the global routing table should be reasonably small.

I fail to see a strict *requirement* for the global routing table even at 
border routers.

A typical customer (at least the kind of I imagine using something like 
this) would be one connecting to two operators operating in the same 
region.   The global connectivity would be more or less the same.  Sure, 
there could be differences and optimizations of dozens of milliseconds, 
but that wouldn't be a major problem.

More likely than not, having just two default routes would be "good 
enough".  If one wanted more granularity than that, adding the prefixes 
directly connected to each ISPs to be explicitly preferred through that 
ISP could optimize the scenarios quite a bit.

Remember -- the ISPs *do* inter-connect locally these days, except in 
some developing areas.  And in that case, the choice of the ISP for 
outbound packets really don't matter much at all, as long as it just 
works..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: leo vegoda <[email-masked]>
Date: Mon, 13 Oct 2003 08:03:36 +0200

Iljitsch van Beijnum <[email-masked]> wrote:

[...]

>show immediate use for a /22 (in the RIPE region).

That's not quite right. If you just want IPv4 address space for yourself 
then you can get whatever you'll use efficiently. If you need a /29 then 
that's what you'll get. If you need a /15 then that's what you'll get. 
Only if you want to assign address space to your customers do you have 
to show usage of a /22 (for you an all your customers combined).

Of course, the policy can be changed if people want it to be.

Regards,

-- 
leo vegoda
RIPE NCC
Registration Services Manager

---

From: masataka ohta <[email-masked]>
Date: Mon, 13 Oct 2003 17:50:38 +0900

Pekka;

> but that wouldn't be a major problem.

You are saying there were geographical aggregation.

There is not.

Otherwise, go with geographic aggregation.

It should also be noted that, like geographic aggregation, your
scheme will make some local peeing a single point of failure.

> outbound packets really don't matter much at all, as long as it just 

If only it had worked.

The reality is that partially broken ISP is paritally broken.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Oct 2003 11:59:58 +0300 (EEST)

> scheme will make some local peeing a single point of failure.

I don't think I'm implying that there is geographical aggregation.  
Perhaps my wording "the global connectivity would be more or less the 
same" was confusing.  What I meant is that it really doesn't matter much 
whether your ISP happens to use e.g. Sprint, Level3, or Telia for its 
upstream transit connectivity.. and in consequence, I'd fail to see how 
adding BGP at your site edge router would dramatically help the situation.

There IMHO, as you said, is not geographical aggregation in the sense that
one single point would be providing aggregated global connectivity.

> The reality is that partially broken ISP is paritally broken.

I'm not sure which kind of brokenness you're referring to -- sometimes,
the ISPs are broken in such a way that even having the full BGP feed at
your site would not help (routing OK but packets get dropped).

It's possible to remove the default route for the other ISP if it's
broken, or to add more specifics to point to the working ISP if necessary.

---

From: masataka ohta <[email-masked]>
Date: Mon, 13 Oct 2003 18:18:18 +0900

Pekka;

> broken, or to add more specifics to point to the working ISP if necessary.

Exactly. And the easiest way to do so is to have full route.

If you are not convinced, here is a reality check.

How many of multihomed (non-transit) entities today are using the default-only approach?

						Masataka Ohta

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Mon, 13 Oct 2003 11:27:53 +0200

> my home network and the link to the colo ISP. (Do some traces for

Then....What's the matter ? I didn't quite catch what you need.
to set up this topology. Do you need a higher block of IPv6 addresses ?
or it's that you need to manage your own routing ?

-- 
JFRH

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Mon, 13 Oct 2003 11:38:59 +0200

> And, you want to have 2 exit routers, if you want to avoid a single

IMO, you don't have to have a global routing table to do this.

> exit router for each destination.

The same here.

> case, the exit routers must have a global routing table.

Do you need to have a global routing table to make "source based routing" ?
(I thought it was just the opposite, you should need a global routing table to
make "destination based routing")

Cheers.

-- 
JFRH

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Oct 2003 12:45:22 +0300 (EEST)

> How many of multihomed (non-transit) entities today are using the

Uhh, quite many?  There are a lot more ways to "multihome" than just 
getting an AS, prefix, and BGP feed from two ISPs.  I think many actually 
use solutions like FatPipe WARP (http://www.fatpipeinc.com/), or 
LinkProof to get a subset of multihoming benefits.

Perhaps there is a partial mismatch of assumptions.

For me, the home or small office users could want to start want 
multihoming too.  For them, BGP-like mechanisms and full routing tables 
seem like an overkill.  For midsize enterprises I would like to say the 
same, unless they insist otherwise.  For really big enterprises, it seems 
fighting against them seems like a battle against the windmill.

What we need is a set of rather simple and workable multihoming procedures
which don't need (global) routing protocols, public AS numbers or provider
independent addresses.  But that procedure need not be exclusive, "the
only way".  For e.g. bigger organizations, there could be different
methods.

Maybe you're mostly concerned on those (big) folks who multihome today, 
with known mechanisms.  Maybe multiaddressing fits to some of their 
objectives, maybe not.  But even if it does, they should be able to handle 
a pretty large routing table because .. well.. they already do it today.

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Mon, 13 Oct 2003 11:55:23 +0200

> Exactly. And the easiest way to do so is to have full route.

Hello Ohta :)

Now I see your point. I think it is the easiest way because
BGP takes care of broken paths automatically. On the other
hand, there are other possibilites which doesn't imply the need
of full routing. E. g, you could check connectivity with your upstream
provider and realise when that is broken to divert traffic to the
other exit router....

> How many of multihomed (non-transit) entities today are using the

Good point, though I don't think the IPv4-way of doing multihomed things
should be the example to follow for IPv6-multihomed sites...

Have fun !

-- 
JFRH

---

From: masataka ohta <[email-masked]>
Date: Mon, 13 Oct 2003 19:25:43 +0900

Juan Rodriguez Hervella;

> IMO, you don't have to have a global routing table to do this.

No, of course.

> The same here.

Wrong.

> Do you need to have a global routing table to make "source based routing" ?

No, not at all.

						Masataka Ohta

---

From: masataka ohta <[email-masked]>
Date: Mon, 13 Oct 2003 19:33:30 +0900

Pekka;

> LinkProof to get a subset of multihoming benefits.

If you think they are "multihome", feel free to use it with IPv6.

Or, accept the reality.

> Perhaps there is a partial mismatch of assumptions.

Between assumptions of yours, yes.

> fighting against them seems like a battle against the windmill.

Your wrong assumption here is that full routing table is large.

> only way".  For e.g. bigger organizations, there could be different

What we need is a workable multihoming solution.

> with known mechanisms.

That is your mistake.

> Maybe multiaddressing fits to some of their 

That's why full routing table should be small.

							Masataka Ohta

---

From: "Ray Plzak" <[email-masked]>
Date: Mon, 13 Oct 2003 07:52:22 -0400

Ohta-san,

The policy can only be for existing protocols/technology.  It doesn't
hurt to consider what an allocation policy should be when considering a
new or revised protocol.

Ray

> Sent: Sunday, October 12, 2003 11:40 AM
> To: Ray Plzak
> Cc: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Oct 2003 12:13:12 +0200

On maandag, okt 13, 2003, at 11:27 Europe/Amsterdam, Juan Rodriguez 

> or it's that you need to manage your own routing ?

There are two problems. The first is that I have no way to keep the 
source address and outgoing ISP consistent. Fortunately, the ISP I 
point my default to doesn't bother with any ingress filtering for IPv6. 
(Hm, I should try and see if they don't do it for v4 either.) Source 
address based routing would help some here, but it doesn't really fix 
the problem.

And of course when something bad happens my sessions break because 
those are tied to a single pair of source/dest addresses.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Oct 2003 12:31:48 +0200

> That's not quite right. If you just want IPv4 address space for 
> yourself then you can get whatever you'll use efficiently. If you need 
> a /29 then that's what you'll get. If you need a /15 then that's what 
> you'll get. Only if you want to assign address space to your customers 
> do you have to show usage of a /22 (for you an all your customers 
> combined).

With "your own address block" I mean either a PI block or a PA block, 
NOT an assignment out of someone else's PA block.

So are you saying that I can get a PI /29 if I want to?

Many people would be ecstatic if they could get PI /24s or /23s as 
those are reasonably routable and 24 or 23 bits is much easier to 
qualify for than 22, or even 20 as I gather ARIN requires.

---

From: leo vegoda <[email-masked]>
Date: Mon, 13 Oct 2003 15:29:51 +0200

Hi Iljitsch,

Iljitsch van Beijnum <[email-masked]> wrote:
>>do you have to show usage of a /22 (for you an all your customers combined).
>

You can if you'll use the /29 efficiently.

>qualify for than 22, or even 20 as I gather ARIN requires.

They can get a /24 or a /23 (or more - or less) if they'll use the 
address space efficiently.

It is worth noting that there is currently a Task Force looking at 
possible changes to this policy. You can join the list at:

    <http://www.ripe.net/mailman/listinfo/pi-tf>

and review the archives at:

    <http://www.ripe.net/ripe/mail-archives/pi-tf/>

Best regards,

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Mon, 13 Oct 2003 16:37:02 +0200

> address based routing would help some here, but it doesn't really fix

Hi again :)

About the first problem, I think that "source based routing" can help a lot.
You only have to read the source address of the packets and re-route
those that are not consistent with the prefix of the exit border router
they've been sent to.

> those are tied to a single pair of source/dest addresses.

I completely agree with you on this problem.  
Is there any other workaround but putting
forward the id/loc separation model ?

PS: The subject line doesn't look like what we're discussing, should we
start a new thread ? I don't come up with a new one yet   ^--^

Thanks for your time!

-- 
JFRH

---

From: Simon Woodside <[email-masked]>
Date: Tue, 14 Oct 2003 03:35:52 -0400

On Monday, October 13, 2003, at 01:42  AM, Pekka Savola wrote:

> some developing areas.

Even in developing areas they are doing it too.... IXPs are cropping up 
everywhere in Africa, etc. as people realize they are getting totally 
screwed by the transit providers.

An interest of mine.

simon

--
www.simonwoodside.com :: www.openict.net :: www.semacode.org
                     99% Devil, 1% Angel

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Oct 2003 11:49:16 +0300 (EEST)

> screwed by the transit providers.

Sure, but it has been pointed out (in context of geographically assigned
addresses) multiple times as an argument that in some areas that just
isn't done as well as one could hope.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 13 Oct 2003 21:49:05 +0200

On söndag, okt 12, 2003, at 16:28 Europe/Stockholm, Iljitsch van 

>> If you want to be 'visible' with a smaller block you are an

Root-servers have addresses allocated to them in IPv6. Not an issue for 
any of the current root-servers...

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 13 Oct 2003 21:58:34 +0200

On söndag, okt 12, 2003, at 23:04 Europe/Stockholm, Iljitsch van 
Beijnum wrote:

> address blocks for all the roots together in a special range. Bonus: 
> we get to hardcode the root addresses now too, as we're now no longer 

I am not following this at all.

I both IPv4 and IPv6 the root-servers use only a single address....

We need a block of some sort of size to get that that address. Most of 
the root-servers have been there so long that the address they use is 
in a /16 block or larger. That /16 might include a lot more than 
root-servers....

The root-servers addresses of today are no more hardcoded than before. 
Root-servers do change addresses, although very seldom.

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Oct 2003 13:17:27 +0200

On maandag, okt 13, 2003, at 21:58 Europe/Amsterdam, Kurt Erik 

>  am not following this at all.

> in a /16 block or larger.

Actually I think many of them use /23s. (I was going to write "in IPv4" 
but then it would seem there are actually root servers in IPv6, but 
we're still waiting for those.)

> Root-servers do change addresses, although very seldom.

You are describing today. I'm interested in doing things differently 
tomorrow. It makes more sense to make the root addresses fixed and move 
the address to the server, rather than take whatever address the server 
happens to have and then publish it in the list of root server 
addresses.

See my next message on the IPv6 wg mailinglist, btw.

Iljitsch

---

From: masataka ohta <[email-masked]>
Date: Thu, 16 Oct 2003 00:39:27 +0900

Juan Rodriguez Hervella;

>>Exactly. And the easiest way to do so is to have full route.

Hello.

> BGP takes care of broken paths automatically.

Routing protocols are the protocls to automatically care
(lack of) connectivity.

> On the other

What end users CAN NOT accept is complex configuration.

A proposal to force end users some action is NO acceptable.

With BGP configuration effort of an end user is variable and,
if most end users can just use AS-path-len, it can be a default
of most routers.

Or, some end users may change weight on length of AS-path
depending on its incoming interface.

Very few will want more advanced control

> Good point,

It is phychologically unacceptable for operator of a multhomed
site that paid connection to some ISP will NEVER be used.

> though I don't think the IPv4-way of doing multihomed things

which is what RIRs are doing.

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Wed, 15 Oct 2003 19:37:55 +0200

On Wednesday 15 October 2003 17:39, masataka ohta wrote:
[snipped]
> What end users CAN NOT accept is complex configuration.

The idea might be as complex as you want to, as long as
the implementation makes it easy for end-users. I'm just 
giving ideas. You can think of it like this:

mh-router-shell (config)> ipv6 multihomed up

Do you think that's difficult for end-users ?

> A proposal to force end users some action is NO acceptable.

So it should be better to let the end-user deal with the full IPv6
routing table, I think he/she will have a lot of fun seeing a lot
of prefixes on the screen when he/she can not reach some host.
This is just a funny comment, cause I totally agree with you on this
point.

> if most end users can just use AS-path-len, it can be a default

As Pekka told in a previous mail on this thread, I think 
that making a BGP solution for SOHO users seems
a bit overkilled. Therefore, I would like to see other possible
choices. We should also deploy other alternatives, so that 
end users could get what they think best fits them.

Besides, I would like to see what requirements do you need
to build up your solution. Have you come up with some of them ?
I think that one of the problems (problems = requirements for end-users)
of your solution is that you will have to have ASNs for every multihomed-user.
And I guess this is only the beginning.

I can not comment without further info. Will you make a requirements-draft 
so we can start making some comments on it ? 

> site that paid connection to some ISP will NEVER be used.

"Money for nothing" is not a good deal, that's clear.

Just I don't understand why you say "it will NEVER be used".
It's our duty to develop mechanisms in a proper way so things get to
be used, is not it ?

> which is what RIRs are doing.

Omg, I'm at least I'm on my last comment.... *wink*

I dunno if that's already been said, what should the RIRs be doing ?

-- 
JFRH

---

From: masataka ohta <[email-masked]>
Date: Thu, 16 Oct 2003 07:32:33 +0900

Juan Rodriguez Hervella;

> This is just a funny comment, cause I totally agree with you on this

That is

Pekka> It's possible to remove the default route for the other ISP if it's
Pekka> broken, or to add more specifics to point to the working ISP if
Pekka> necessary.

can not be an option for end users.

> a bit overkilled.

Pekka eventually said, don't rely on routing protocols and use
static routing, which is the overkill.

Non-BGP solution for SOHO users is the overkill.

End users can swallow full routing table, if the size is
reasonable and inexpensive routers can accept by default.

Your example;

> mh-router-shell (config)> ipv6 multihomed up

is unnecessarily complex. That is, router comfiguration should
be same, regardless of whether you are multihomed or not and
the factory default should work in all cases.

> And I guess this is only the beginning.

Not at all.

As the end users do not offer transit, they don't really have to
have ASNs. The end users accept all the route and generate none.

So, we can modify BGP. Or, keep BGP as is and have a psuedo ASN
shared by all the end users. BGP daemons on border routers of
ISPs should filter out any information from the end users that
the psuedo ASN won't be visible.

> so we can start making some comments on it ?

The requirement is to make routing table reasonably small.

Have you read:

	draft-ohta-multihomed-isps-00.txt

> It's our duty to develop mechanisms in a proper way so things get to

Oops, I mean "NEVER unless the default ISP is completly down".

I won't request (outgoing) load be fully distributed over
all the external links. But, if you are triply homed, and
if the third link is not used for outgoing traffic unless
the first and the second ISPs are down, it is not acceptable.

> I dunno if that's already been said, what should the RIRs be doing ?

We can't expect much on RIRs for protocol development.

						Masataka Ohta

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 16 Oct 2003 10:24:25 +0200

Hello Ohta,

I'm really enjoying the discussion, so please go on,
keep you up and see my comments below ^--^

> can not be an option for end users.

I'm sorry to say I can not agree with you. I still don't see
why it must be only one solution, specially for SOHO users.
If we are able to make an alternative solution which remains
bounded to what the end-user can use *now*, I think it will
be easier than making the ISPs talk BGP with their SOHO 
costumers. We've got room for other possibilities, at least in 
the short term.

After reading your draft, do you think it's feasible
to keep a small set of TLAs ? This is a requirement
for the whole IPv6 policy, which is worse than a requirement
for the end-user, IMHO.

> the factory default should work in all cases.

What about this example ? I hope you will like it more.

**** mh-router booting IPv6 IOS.....
**** mh-router booting finished at 2020/10/16.
(console)>

PS: If this resembles cisco, it's just a matter of chance.

Cheers
-- 
JFRH